[Octave-bug-tracker] [bug #34266] Four issues with "residue" and residuez"

[Jordi Gutiérrez Hermoso]

Update of bug #34266 (project octave):

                Category:               Libraries => Interpreter            

    _______________________________________________________

Follow-up Comment #11:

Bernie wrote:
> I am nearsighted so small print and large screens are a must for me.

Is changing the fontsize not an option? Long lines are visually
jarring and break with our coding standards. Except in rare cases, we
try to keep Octave code at 80 columns or less.

> I am not sure who Sage is or what the stable branch is – but it
> sounds good.

Sage is a free CAS (http://sagemath.org), and the stable branch is
where we put bugfixes for the next stable release of Octave. We use a
two-branch development model, a stable branch for relatiely safe
bugfixes and improvement, and a development branch for more radical
changes we're unsure of.

> At the present time, I believe that trimming of the polynomial
> coefficients should be eliminated from the Octave code. The user
> should decide if he wants to reduce the polynomials in his code.

I don't think we can do this. It seems awkward and would likely break
Matlab compatibility if no coefficients ever get trimmed unless
explicitly requested by the user. You really can't suggest a better
way to pick this tolerance?

> Jordi wrote:
> > Further, even with that suggested change, your test fails because
> > the tolerance is too low for br and b. Is this also a bug with
> > residue or should your test allow for higher tolerance?

> For a 64-bit system, the machine accuracy (eps) is
> about 2.22x10-16.

This accuracy is irrelevant of the machine architecture; it's simply
the eps of an IEEE 754 double. It's very rare nowadays to compile
Octave for machines that do not obey IEEE 754, so it's usually safe
that this value is the eps of 1.

> For most poles, the tolerance should be better than 1e-12. But,
> there are outliers so that the assert test should be done
> pole-by-pole with variable tolerances. This is rather complicated so
> I used just 1e-8 as a compromise.

I think we need a more careful analysis of the error here to decide
what we should choose.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34266>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/