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]>:
> 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.
>
--
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.
