Why reinvent the wheel? A symbolic polynomal class should be capable of a type checking of the coefficients and transform the polynomial internally into the correct setting and then call the correct algorithms and methods.
The main purpose of such a class is that the user can work intuitively with polynomials, without worrying about the right rings and types. The main challenge for that is to design an intelligent default behavior, which is satisfying for the most use cases. If the usage of the class is inconvenient for some use cases, one could go back to the classical polynomial rings. The other benefit is the possibility to extend the class for symbolic usage. On Wednesday, December 18, 2013 12:04:28 PM UTC+1, Simon King wrote: > > Hi again, > > On 2013-12-18, maldun <[email protected] <javascript:>> wrote: > > 1) I think that applying Polynomial division by commands like > > > > sage: f(x)=3Dx^3+5*x^2-3*x+1 > > sage: g(x)=3Dx+1 > > sage: f.maxima_methods().divide(g) > > [x^2 + 4*x - 7, 8] > > > > are not very intuitive. > > These aren't polynomials but symbolic expressions. If you want > polynomial division, use polynomials: > > sage: P.<x> = QQ[] > sage: f = x^3+5*x^2-3*x+1 > sage: g = x+1 > sage: f.quo_rem(g) > (x^2 + 4*x - 7, 8) > sage: f//g > x^2 + 4*x - 7 > sage: f%g > 8 > sage: f == (f//g)*g + f%g > True > > > 2) As mentioned direct call of algorithms (e.g. compute gcd, Gr=F6bner > basi= > > s etc.) > > ... which exists in Sage. Just use polynomials and not symbolic > expressions. > > > > 3) More symbolic manipulation possibilities for specific for symbolic > polyn= > > omials. > > Right, that's in the "symbolic expression world". > > > 4) faster and numerical more stable evaluation methods > > Is there a reason to not implement this on the level of the *existing* > polynomials with coefficients in RR or CC? > > Up to now I don't see a compelling reason for introducing yet another > class of polynomials. One should use the right tool for the job. In > the job examples you gave, it seems to me that symbolic expressions > are not the right tool, but there *are* easily accessible suitable > tools in Sage. > > - for 1) you will probably be able to use existing polynomial classes, > which will be a lot faster than calling maxima---unless you have > quite exotic coefficients, but in this case the notion of division > with remainder might not even make sense. > > - for 2) you certainly do not want to re-invent the wheel. Sage uses > (mainly) Singular to do Gröbner computations when working with > coefficients in finite fields and QQ, and I think ZZ and function fields > as well. If you want to beat Singular with an implementation that is > based on symbolic expressions, you should be prepared for some years > of work. Again, if you have exotic coefficient domains that Singular > can't deal with, then a new implementation might make more sense. In > this case: There is a toy implementation of the Buchberger algorithm > and I think also of F5 algorithm somewhere in Sage, which should work > with exotic coefficients and which you may try to improve. > > - for 3), this makes sense. The question is if this requires a whole new > fully fledged polynomial class. > > - for 4), it seems to me that this should be done in > sage.rings.polynomial.polynomial_real_mpfr_dense.PolynomialRealDense > respectively in > > sage.rings.polynomial.polynomial_element_generic.Polynomial_generic_dense_field > > > > Best regards, > Simon > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
