Karim BELABAS on Sat, 1 Mar 2003 15:55:39 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: gp: a/b/c == (a/c)/b ? |
>>> 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]