This isn't exactly a question of mathematical correctness, but of usability. Think of users who aren't mathematicians, but engineers or from physics. Most of them even don't know the difference between a polynomial from ZZ or RR.
So the goal should be a good default behavior which covers 70-90% of all standard use cases. A way would be to let the class look for the smallest ring where all coefficients are in (e.g. (6*x^2 - 12) should be identified as element of ZZ[x]) and then apply factorisation over that ring. (compare with other CAS like Mathematica or Maple) Of course one could argue that this should eventually be done by the preparser. But a specific class could help providing clean conversion methods. On Wednesday, December 18, 2013 6:58:15 PM UTC+1, vdelecroix wrote: > > Users of polynomials should worry about the coefficient ring. What do > someone should expect of > > sage: (6*x^2 - 12).factor() > > The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic > polynomial there is no way to make it coherent... > > Moreover, I feel very uncomfortable having an extra layer with > symbolic polynomial. Most of the time, the symbolic ring should just > be avoided. And I guess a long term goal of Sage would be to make it > disappear. > > Vincent > > 2013/12/18, maldun <[email protected] <javascript:>>: > > 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] <javascript:>. > > To post to this group, send email to > > [email protected]<javascript:>. > > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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.
