|Bill Allombert on Fri, 5 May 2000 10:39:47 +0200 (MET DST)|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Bug in Mod (2.0.15)|
>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.