#11126: Fix category of Symbolic Ring
-------------------------------------+-------------------------------------
Reporter: duenez | Owner: burcin
Type: defect | Status: needs_info
Priority: major | Milestone: sage-6.4
Component: symbolics | Resolution:
Keywords: symbolic ring | Merged in:
category | Reviewers:
Authors: Peter Bruin | Work issues:
Report Upstream: N/A | Commit:
Branch: | 82b9860a3d47ee19f944a3b357b9d0e943226a54
u/pbruin/11126-SymbolicRing_not_domain| Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Changes (by vdelecroix):
* status: needs_review => needs_info
Comment:
Hello,
I really do not like the strategy. Starting to have special cases for the
symbolic ring will be a nightmare to write and maintain. The symbolic ring
is definitely an ugly (and very useful) piece of code but it should not be
intrusive. Not speaking about the fact that a line like `from
sage.symbolic.ring import SymbolicRing` takes time to be executed. The
current situtation that makes SR thinks that it is a field looks much more
natural to me: keep the bullshit in one place.
And do you really think that we should support elliptic curves over the
symbolic ring? I saw that there is an example in the doc, but we could
just ignore it. From my perspective, `SR` should not even be a ring.
Could you give more motivation of changing the current situation? I do not
get it from the ticket description?
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/11126#comment:15>
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 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-trac.
For more options, visit https://groups.google.com/d/optout.
