Re: gp: a/b/c == (a/c)/b ?

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

>>> It depends on the order in which the variables are introduced to the
>>> stack.

Right.

? a;b;c; c/a/b == c/b/a
%1 = 0

On Fri, 28 Feb 2003, Igor Schein wrote:
> I stand corrected again.
>
> It was broken between versions 2.0.14 and 2.0.19 ( possibly earlier ),
> then it was fixed in 2.0.20 and worked until 2.2.5, and now it's back
> to broken.

More precisely, it's been broken forever, but went into hiding for extended
periods of time as a side effect of various other changes affecting
polynomial arithmetic.

1) Main problem: == [ gegal ] was incorrect for constant polynomials, due to
the consideration of irrelevant variable numbers.

2) There was a partial fix for this (disregard variable numbers for constant
polynomials), but it was still not correct because you could have an
arbitrary stack of constant polynomials in various variables, whose bottom
value was the correct polynomial.

3) What happened in 2.2.5 was that the gmul(scalar, t_RFRAC) routine was
corrected. And the (generic) fix could introduce one more "constant
polynomial layer" [ i.e return constant polynomial in x, whose scalar value
is a t_POL in y ].

I fixed:

  1) in gegal() [ actually polegal(), by poping out the entire stack first ]

  3) by making my previous fix less generic, explicitly preventing this
from happening [ only led to inefficiencies, served no useful purpose ].

===========================================================================

I used to think that consistency was of the utmost importance and that an
arithmetic operation between polynomials in variable X, should return a
polynomial in the same variable X, even if it were constant. Nowadays, I
believe that _generic_ routines (gadd, gmul, etc) should make a modest
attempt at simplification, and return a constant instead of a constant
polynomial. Currently, we have a lot of code accomplishing the effect of

    while (lgef(x) == 3) { x = (GEN)x[2]; if (typ(x) != t_POL) break; }

[ this is actually a corrected form. The way it is done in most places
is broken ]. And whenever analogous code is missing or is broken, we have
inefficiencies, and possibly wrong results in extreme cases as above.

Internal specialized routines (reserved for polynomials in the same variable)
would still only accept and return t_POL, which does avoid many unnecessary
type checks in internal routines.

    Karim.

P.S: Note that the current "consistency" attempt
1) is not documented
2) is actually broken in many, many, places.

Hence, it only serves to introduce unnecessary confusion:

* users can't rely on getting a polynomial from any given set of public
routines, even if they were aware that this was to be generally enforced

* they actually get many zeropol() or scalarpol(), which they'd rather get
rid of.
-- 
Karim Belabas                     Tel: (+33) (0)1 69 15 57 48
Dép. de Mathématiques, Bât. 425   Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud              http://www.math.u-psud.fr/~belabas/
F-91405 Orsay (France)            http://www.parigp-home.de/  [PARI/GP]