Open 89f39f15-88e8-4e79-9bc0-0739a7fc497c opened 11 years ago
Changed dependencies from #13670,#13671,#13675 to #13670,#13671,#13675,#13714
Attachment: improve_quotient_ring.patch.gz
Author: Charles Bouillaguet
I'll rebase this patch and try to review it.
rebase of Bouillaguet's patch
Description changed:
---
+++
@@ -36,3 +36,9 @@
* test for regularity before dividing (mathematically better, may be **much** slower)
* Clarifying all this would then open the possibility to have, for example, special code to deal with ideals given by a regular chain instead of a Groebner basis
+
+---
+
+Apply
+
+1. [attachment: trac_13697.patch](https://github.com/sagemath/sage-prod/files/10656599/trac_13697.patch.gz)
Branch: u/saraedum/ticket/13697
Description changed:
---
+++
@@ -19,7 +19,7 @@
S(2)
sage: S(2) * S(x) == S(2*x) # indeed, division works correctly....
True
- sage: S(2+x) * S(x) == S(2*x) # but several "quotients" are possible, because ``S(x)`` is a zero-divisor
+ sage: S(2+x) * S(x) == S(2*x) # but several "quotients" are possible, because ``S(x)`` is a zero-divisor
In contrast, univariate polynomial rings behave more rigorously:
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:756831a] | added a doctest for QuotientRingElement.is_unit() |
[changeset:1967e3b] | removed trailing whitespace and semicolons from docstrings |
Commit: 756831a
Your patch does not address all the questions in the Ticket summary. How do you want to proceed with this? Should we split this and move the issues to new tickets?
I ran into the following:
sage: R.<x,y>=QQ[]
sage: Q.<xx,yy>=R.quotient(x^2-y^3)
sage: xx/yy
...
ArithmeticError: Division failed. The numerator is not a multiple of the denominator.
It would be nice if in this situation, the quotient ring could check if it is a domain, and if so, return xx/yy
as an element of the fraction field.
Branch pushed to git repo; I updated commit sha1. New commits:
6276d0b | Merge branch 'develop' into t/13697/ticket/13697 |
Changed keywords from none to sd86.5
The class
QuotientRingElement
, which implements the operations an element of the quotientR/I
of a ringR
by an idealI
, suffers from several problems and limitations. Most of these were uncovered while working on #13670 and #13675.While
QuotientRingElement
aims to be generic, it contains code dedicated to the case whereR
is a multivariate polynomial ring. In particular, the implementation of division first checks ifR
supports the computation of Groebner bases. This is not the proper way to go ; a special class should be created, following the approach taken for univariate polynomial quotient rings (PolynomialQuotientRing
,PolynomialQuotientRingElement
). We should createMPolynomialQuotientRing
andMPolynomialQuotientRingElement
, and host multivariate-polynomial-specific code here.The
is_unit()
function does almost nothing (it checks if its argument is a unit inR
). In the case of (multivariate) polynomial rings, an actual test can be implemented.The class lacks an
is_regular()
methods (that detects zero divisors).In the case of (multivariate) polynomial rings,
is_regular()
can be implemented.The interest of
is_regular()
is that division byx
should only be allowed ifx
is regular.The present implementation of division has problems. It contains multivariate-polynomial-specific code, which is bad. Furthermore, it allows division by zero-divisors, even tough the result is not defined :
In contrast, univariate polynomial rings behave more rigorously:
This raises the question of how we want division to proceed:
Clarifying all this would then open the possibility to have, for example, special code to deal with ideals given by a regular chain instead of a Groebner basis
Apply
Depends on #13670 Depends on #13671 Depends on #13675 Depends on #13714
Component: commutative algebra
Keywords: sd86.5
Author: Charles Bouillaguet
Branch/Commit: u/saraedum/ticket/13697 @
6276d0b
Issue created by migration from https://trac.sagemath.org/ticket/13697