Re: polcoeff() mystery

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

On Mon, 15 Jul 2002, Ilya Zakharevich wrote:
> On Sun, Jul 14, 2002 at 05:37:54PM +0200, Karim BELABAS wrote:
> > > Which algorithsms assume that a poly is "filled"?
>
> > Nearly everything operates on "filled" single variable polynomials. Once the
> > higher level wrappers have done their stuff [ checking types, degrees, variable
> > priorities, etc ], lower level routines assume everything is compatible (all args
> > in sight are t_POL in the same variable) and operate on vectors of coefficients.
>
> Do you mean here the support for base arithmetic, or higher-level
> stuff?  If former, it is not out-of-hand to fix...

The following assumption occurs in _many_ places in the code: if x, y are
t_POL in variable v, then so is f(x, y), for all low-level routines f,
like gadd / gmul / gres, etc.  [ f(x,y) may be of degree 0, or -oo of course ]

> > > > Maybe a print function that output 'foo^0 as 'foo^0 not 1 could be useful.
> > >
> > > \x *must*.
> >
> > \x *does*. Disable automatic simplification (\y) if you want \x to operate in the
> > way you expect.
>
> This confuses me again, when I felt almost unconfused...  Consider:
>
>   ? aaa=x^2 + y*x + z;
>   ? aaa
>   %2 = x^2 + y*x + z
>   ? \x
[...]
> If every polynomial is filled, then aaa contains a filled poly, then
> coefficient of degree 2 of aaa must be a polynomial in y - no matter
> whether the simplifications are enabled or not.  Right?

I was unclear in my previous messages. Most polynomial are not "filled"
in the sense implied in your query. x^2 + y*x + z (input as is) is really

  x^2 * 1 + x^1 * (1*y^1 + 0*y^0) + x^0 * y^0 * z

This is not necessary: if input is x^2 + simplify(y*x) + z, one gets

  x^2 * 1 + x^1 * (1*y^1 + 0*y^0) + x^0 * z

which is also a correct object.

What I meant is that most pari routines handle and produce univariate
polynomials (for some irrelevant coefficient ring). So a given
multivariate polynomial, depending on its "history" may contain lots of
polynomials of degree 0, which are only removed by simplify() [which is
hardly ever called in the library code].

The routines do not care whether a polynomial is "filled" or not, but high
level routines expect consistency when calling lower lever ones [and
certainly never check return types].


This got mingled with another point, namely that \x does not operate on aaa.
It operates on %2, which is equal to simplify(aaa), assuming automatic
simplification is enabled. Hence part of the confusion.

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/