[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to residue.m
From: |
Daniel J Sebald |
Subject: |
Re: Patch to residue.m |
Date: |
Mon, 31 Dec 2007 11:47:11 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
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