#1956: implement multivariate power series arithmetic
---------------------------------------------------------------------------------------------------+
Reporter: was
| Owner: pernici
Type: enhancement
| Status: needs_work
Priority: major
| Milestone: sage-4.6.1
Component: commutative algebra
| Keywords: multivariate power series
Author: Niles Johnson
| Upstream: N/A
Reviewer: Martin Albrecht, Simon King
| Merged:
Work_issues: multivariate series on 1 generator should remain different from a
univariate series |
---------------------------------------------------------------------------------------------------+
Changes (by SimonKing):
* status: needs_review => needs_work
* work_issues: multivariate series on 1 generator => multivariate series
on 1 generator should remain different
from a univariate series
Comment:
Replying to [comment:67 niles]:
> I think that the top-level constructors `PolynomialRing` and
`PowerSeriesRing` should return univariate rings instead of multivariate
rings in one variable.
It already does:
{{{
sage: R.<x> = QQ[]
sage: R
Univariate Polynomial Ring in x over Rational Field
sage: R2.<x> = PolynomialRing(QQ)
sage: R2
Univariate Polynomial Ring in x over Rational Field
}}}
Only when you explicitly request it, you'll get a multivariate ring with
one variable:
{{{
sage: R3.<x> = PolynomialRing(QQ,1)
sage: R3
Multivariate Polynomial Ring in x over Rational Field
}}}
> It is difficult to imagine a situation where someone would want access
to the "multivariate in one variable" versions
I find it very easy to imagine. I sometimes want it so, because multi- and
univariate polynomials have different methods, and thus I want to make
sure that my programs will always get a ''multi''variate polynomial.
> (e.g. they want to use some algorithm implemented for the multivariate
case that is not available in the univariate case), and even more
difficult to imagine that this is the preferred option of most users.
Agreed, and this is why the polynomial ring constructor returns a
univariate ring, unless requested otherwise (in contrast to your claim).
> Someone who does need this functionality can still import the
multivariate constructor directly.
No, one shouldn't, it is deprecated:
{{{
sage: MPolynomialRing(QQ,1,'a')
/mnt/local/king/SAGE/sage-4.6/local/bin/sage-ipython:1:
DeprecationWarning: MPolynomialRing is deprecated, use PolynomialRing
instead!
#!/usr/bin/env python
Multivariate Polynomial Ring in a over Rational Field
}}}
Instead, one should choose the arguments of the polynomial ring contructor
appropriately (as I did above).
> With [attachment:trac_1956_one_variable_fix.patch] we have:
>
> {{{
> sage: PowerSeriesRing(QQ,1,'a')
> Power Series Ring in a over Rational Field
>
> sage: PowerSeriesRing(QQ,1,'a') is PowerSeriesRing(QQ,'a')
> True
> }}}
I am strongly -1 to that suggestion, because the user must have the
possibility to choose the implementation by providing appropriate
arguments (with the argument `1` versus without it).
> {{{
> sage: from sage.rings.multi_power_series_ring import
MPowerSeriesRing_generic
> sage: MPowerSeriesRing_generic(QQ,1,'a')
> Multivariate Power Series Ring in a over Rational Field
> }}}
Using a non-generic constructor should be deprecated, IMO.
> Unless someone here can think of a compelling reason to reverse this
change, I think we should also open a new ticket for the polynomial case.
I don't know if you find my argument compelling, but I am strongly against
that suggestion.
> In a related vein, we also have polynomial rings in no variables, and
these are different from the base ring:
>
> {{{
> sage: PolynomialRing(ZZ,'a',0)
> Multivariate Polynomial Ring in no variables over Integer Ring
> sage: PolynomialRing(ZZ,'a',0) is ZZ
> False
> }}}
>
> For consistency, I've implemented the same behavior for power series
rings:
>
> {{{
> sage: PowerSeriesRing(QQ,0,'a')
> Multivariate Power Series Ring in no variables over Rational Field
> }}}
That's fine.
> Perhaps these should both simply return the base ring --
No! The user has ''explicitly'' requested a polynomial ring. So, s/he
''must not'' get the base ring in return, since s/he may rely on
particular methods that may only be implemented for polynomial rings, but
not for general rings.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/1956#comment:68>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
