Limitation on poly and roots functions?

Dear All,

I have a query regarding the maximum polynomial order that can be treated using "roots" or "poly" functions. I am facing following problem:

P= Polynomial of order N=512;

R=roots(P);

P1=poly( R );

Coefficients of P are not equal to P1.

Coefficients match for lower orders such as N=8, 16, 64, 128. I shall appreciate if anyone could explain this to me or suggest what I am missing here. Thanks in advance.

Asim

Answer 1

[Adam Filion]

Note from the documentation: "For vectors, roots and poly are inverse functions of each other, up to ordering, scaling, and roundoff error."

So these are not perfect inverses of each other. I ran your test through a loop of N=1:1024 using random inputs and for each iteration P==P1. However I'm sure there's some cases out there where they won't be exactly equal, particularly with larger values. Are you seeing very small differences, or are they significant? If they are small then I would guess it is expected.

[Asim]

Actually, difference is significant! I did perform tests with polynomials ordering: N=16, 64, 128 and 512.

I assumed all above polynomials with unity coefficients and plotted these before and after the conversion. For N=16 we get back the unity coefficients. For N=64 I found uniform variation right at the middle but it stays under 0.9. It gets worse with N=128 and 512 when variation has the order of 10^13!

This is how I dd it;

P=ones(1,N);

P1=poly(roots(P));

plot(P1)

I understand your explanation of round off error but it is significant to ignore.

I would very much appreciate if you could suggest a way around this problem.

Answer 2

[Walter Roberson]

Round-off, I would expect. roots() is a numeric solver and so is limited to the precision of double precision numbers (about 53 bits). Multiply 512 double-precision numbers together, losing one bit of theoretical accuracy due to round-off per multiplication, and you are looking at accumulated error far far bigger than 53 bits of precision can hold.

[Asim]

Thank you for explaining this to me. It would be helpful to know if there is any way around this problem.

[Walter Roberson]

Use the symbolic toolbox with a large number of decimal places. I estimate 155 significant figures would be required for complete reconstruction.