[Octave-bug-tracker] [bug #42742] polygcd fails valid test

[Dan Sebald]

Follow-up Comment #2, bug #42742 (project octave):

In the polygcd() routine is this line:


         r = r(nz(1):length(r));


Are the zeros of r always assured to be at the front of the array?  Perhaps
so.

Anyway, is there another way of solving this instead of using deconvolution? 
The documentation states:

"This is equivalent to the polynomial found by multiplying together all the
common roots."

It is pretty straightforward to compute the roots of both of the polynomials
using the roots() function.  Then if one were to put the roots in order there
could be a fast method of finding common roots (as opposed to a factorial
permutation comparison of all combinations of roots).  Here's an
illustration.


octave-cli:112> p1 = [1 5 7 3];
octave-cli:114> p2 = [3 12 7];
octave-cli:126> r1 = sort(roots(poly(p1)))
r1 =

   1.00000000000000
   2.99999999999998
   5.00000000000003
   6.99999999999998

octave-cli:127> r2 = sort(roots(poly(p2)))
r2 =

    3.00000000000000
    7.00000000000000
   11.99999999999998

octave-cli:128> poly([r1(2) r1(4)])
ans =

    1.00000000000000   -9.99999999999996   20.99999999999983

octave-cli:129> poly([r2(1) r2(2)])
ans =

    1.00000000000000  -10.00000000000001   21.00000000000002

octave-cli:131> polygcd(poly(p1),poly(p2))
ans =

    1  -10   21


All that is needed is the short simple loop inside a loop that picks the
common roots within some tolerance.  (There is the intersect() command, but
that might require equality, I'm not sure.)

The question is whether the proposed approach is any more robust in the case
of polynomial coefficients being large.

    _______________________________________________________

Reply to this item at:

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

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