Re: Patch to residue.m

[Daniel J Sebald]

Doug Stewart wrote:

> > I think you are right.  The roots being off by o(1e-5) seems rather 
> > poor.  Averaging gets to o(1e-15) and machine precision is o(1e-16)?  
> > One would think maybe o(1e-10) or better is achievable.  Maybe you are 
> > trying to improve on something that should be addressed elsewhere, and 
> > if that where fixed your tolerance equations could be simplified.
> >
> > And considering the cast to zero after multiplicity is determined 
> > seems worth investigating.
> >
> > Dan
> For a quadratic there is an exact answer, and for cubics and for 
> quartics:    but there is no exact method for 5th and higher polynomials.
> Using residue one should recognize that it is a numerical approach to 
> find approximate roots and residues. And if you recognize that they are 
> approximate then the values used for tol and small seem appropriate.

But why two?  And why of such drastic different values?


> Yes, if you are looking for roots in the 10e-12 range  then you you will 
> have problems  - but this was true before the improvements.
>
> If you want exact answers try Maxima, I did and found that it didn't 
> even know how to do the exact 3 and 4th order answers..

Not exact, but better, or at least consistent amongst methods.  It appears that 
mpoles() has some code similar to the averaging technique.  Can that code be 
reused somehow so that numerical effects are consistent?

Also, why is it important to have a tighter restriction on poles being zero?  
If one simply uses the averaging technique and pole multiplicity, then there 
might be, say, a multiplicity of 2 at 0.00000313 or something.


> If someone would write a better roots.m file we will all benefit. But  
> it is not an easy task. ( I have been thinking about it since 
> "Numerical  method" course in university in 1982) Using VPA (Variable 
> Precision Arithmetic) yes you can get the roots to the nth decimal point 
> but at a cost of cpu time-- so the conclusion that I have come to is:    
> that this is a step in the right direction and is an improvement over 
> what was here before.

Sure, but so long as it is fresh in the mind, it'd be good to identify if and where there 
is an issue if that means just leaving a comment in the code "root accuracy needs to 
be improved".

Dan