"widmar"
sdynamix.com> wrote in message
news:46DF4957.F6D18C79@sdynamix.com...> mecej4 wrote:
>>
>> I get with Watcom 1.5:
>> s:\>rpoly
>> 3,1,0,-2,-5
>> 2.095E+00 0.000E+00 -1.047E+00 1.136E+00 -1.047E+00-1.136E+00
>>
>> which is in agreement with what Matlab zeros() gives.
>> polynomial = [1 0 -2 -5];
>> theroots = roots(polynomial)
theroots =
2.09455148154233
-1.04727574077116 + 1.13593988908893i
-1.04727574077116 - 1.13593988908893i
>> values = polyval(polynomial, theroots)
values =
1.95399252334028e-014
-1.77635683940025e-015 - 1.77635683940025e-015i
-1.77635683940025e-015 + 1.77635683940025e-015i
Looks pretty reasonable to me.
> Actually this doesn't mean much considering the origins of Matlab code -
> for all you know they made the same mistake (translating a mixture of
> sp/dp machine constants) as you did. It could be worse, awhile back an
> academic cited some theory in trying to explain Matlab's faulty roots...
> try his case,
> p(x) = x^7 - 7*x^6 + 21*x^5 - 35*x^4 + 35*x^3 - 21*x^2 + 7*x - 1
> to see if that theory still holds!? Note, that validation should start
> with solving a known case - only then can you assume you're not
> comparing the *same* algorithm renamed by different commercial brands.
> "cpoly" (predecessor to "rpoly") does just that - provides a number of
> nontrivial cases to verify if any particular *port* passes the grade.
You can also try substituting the roots generated by the program back into
the original expression and see if you get essentially 0 as a result. While
that's not guaranteed to always work (see the last column of Cleve's article
above, but think about a case with larger roots, higher order polynomials,
and more cancellation) it's still a pretty useful check.
