Re: Bug in Mod (2.0.15)

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

>Do not see what you mean.  Which other places (in addition to
>simplify()) depend-on/use the K(y,z,t)[X] hack?

Well I want sometimes really to compute in K(y,z,t)[X] and I do not
want this capability to be removed. Moreover there are lot of
interesting ring beside K[X,Y,Z]. The good solution is to design a
"ring" type to specify in which ring we do the computation.
At least : 
Z[X,Y], Q[X,Y] and Q(Y)[X]

(and perhaps Z[1/2,X,Y], Q[X,Y,1/X] etc...)

There are already some algorithms for in Z[X].

>Given marked generators (x,y,z etc) of the ring, could not we get
>something canonical?

I check it in a book:
No, but does it really matter ?

We only need to be able to: 

_ check wether an element is in an ideal or not.
 
_ Reduce an element modulo an ideal to avoid coefficient explosion.

_ Compute inverse if it exists.

and Groebner basis can handle this.


>Why this obsession with efficiency?  It is good when possible, but
>having *some* pilot implementation will clear the way for future
>improvements...

PARI does not handle sparse polynomials, and this is a big limitation,
even for moderate input. Probably it is better to implement it before
Groebner basis.

Bill.