#11878: Proper implementation of quotients of g-algebras and polynomial rings
---------------------------+------------------------------------------------
Reporter: SimonKing | Owner: AlexGhitza
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.7.2
Component: algebra | Keywords: g-algebra Singular quotient
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies: #4539
---------------------------+------------------------------------------------
Old description:
> The wrapper at #4539 originally tried to use Singular for computations in
> quotients of g-algebras. But for some reasons it did not work, and thus
> it was decided to temporarily use generic quotient rings, so that the
> ticket can be merged.
>
> The purpose here is to use rings constructed by Singular from a "ring
> list", which should provide a more efficient implementation.
New description:
The wrapper at #4539 originally tried to use Singular for computations in
quotients of g-algebras. But for some reasons it did not work, and thus it
was decided to temporarily use generic quotient rings, so that the ticket
can be merged.
The purpose here is to use rings constructed by Singular from a "ring
list", which should provide a more efficient implementation.
There should also be a proper implementation for the commutative case as
well. Currently, generic code is used:
{{{
sage: P.<x,y,z> = QQ[]
sage: I = [x^2+x*y*z,y^2-z^3*y,z^3+y^5*x*z]*P
sage: Q = P.quotient(I)
sage: type(Q)
<class 'sage.rings.quotient_ring.QuotientRing_generic_with_category'>
}}}
--
Comment(by SimonKing):
I broadened the purpose of the ticket: Implementing quotients of
multivariate polynomial rings via Singular should be just as easy as
implementing quotients of g-algebras via Plural.
There is a design problem for the elements, though. I see three
approaches:
1. Have a single class of elements for quotients and non-quotients. Do a
reduction with respect to the modulus (if there is any) when comparing,
hashing or printing elements.
2. Have two separate classes, essentially copying the old
`MPolynomial_libsingular` class for creating a `NCPolynomial_plural`
class. The change would mainly amount to replacing the strings `MP` and
`_libsingular` by `NCP` and `_plural`, respectively.
3. Have two separate classes, but avoid code-duplication. For this to
work, one needs to modify the arithmetic methods of
`MPolynomial_libsingular`, such that for example `left._add_(right)` does
not return a new instance of `MPolynomial_libsingular`, but a new
instance of `left.__class__`.
All three approaches have disadvantages: The first approach may slow down
the arithmetic of polynomials, since any call to hash, repr and cmp would
involve a test whether the parent is a quotient ring. The second would
imply a massive code duplication. The third may, again, slow down
arithmetic, since (as in the first approach) arithmetic is spoiled by
additional tests.
Modern editors are capable to copy-and-paste, and I prefer speed. Thus,
I'll go for the second approach, unless one of you objects.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11878#comment:4>
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.
