#13675: multivariate polynomials lack the inverse_mod(...) method
-------------------------------------------+--------------------------------
Reporter: Bouillaguet | Owner: malb
Type: enhancement | Status: needs_work
Priority: minor | Milestone: sage-5.5
Component: commutative algebra | Resolution:
Keywords: inverse modulo an ideal | Work issues:
Report Upstream: N/A | Reviewers: Marco Streng
Authors: Charles Bouillaguet | Merged in:
Dependencies: | Stopgaps:
-------------------------------------------+--------------------------------
Changes (by mstreng):
* status: needs_review => needs_work
Comment:
Replying to [comment:8 Bouillaguet]:
> should inverse_mod(...) be implemented in multi_polynomial.py or in
multi_polynomial_element.py ???
>
> I don't exactly understand the logic here...
Here's the logic, as far as I understand:
* multi_polynomial.pyx contains the base class MPolynomial
* multi_polynomial_element.py contains polynomials over arbitrary rings,
in the form of the class MPolynomial_polydict
* multi_polynomial_libsingular.pyx contains fast polynomials via Singular,
in the form of the class MPolynomial_libsingular
The lift function, which you use, currently only exists in
MPolynomial_libsingular and MPolynomial_polydict.
The two classes MPolynomial_libsingular and MPolynomial_polydict inherit
from the first (MPolynomial) and there is no more specific class from
which they both inherit.
So if you put inverse_mod in multi_polynomial.pyx directly, without
providing a "lift" method there as well, you run the risk of getting
{{{
AttributeError: '...' object has no attribute 'lift'
}}}
which isn't very helpful, as the word "lift" can mean dozens of things in
mathematics.
So I think that leaves you with two options: either
* implement inverse_mod in both of MPolynomial_libsingular and
MPolynomial_polydict (or only one of them if you don't care about the
other and don't mind doing half a job)
* implement inverse_mod in MPolynomial, and give Mpolynomial a "lift"
method with the same documentation as the "lift" method in the other two
classes, but always raising {{{NotImplementedError}}}
The second option looks best to me, and you're already halfway with that.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13675#comment:9>
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.
