#13215: Skew polynomials
-------------------------------------+-------------------------------------
Reporter: caruso | Owner: tbd
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.3
Component: algebra | Resolution:
Keywords: skew polynomials | Merged in:
Authors: Xavier Caruso | Reviewers: Burcin Erocal
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/arpitdm/skew_polynomials | e189fec13d005a7fba39a429876c501fe95c05da
Dependencies: #13214, #13303, | Stopgaps:
#13640, #13641, #13642 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:68 jsrn]:
> Replying to [comment:67 tscrim]:
> > That must of gotten lost when I had connectivity issues. This was
suppose to be "by using a consistent API".
>
> Ah ok. You're right: aim for a good API. I think that the experimental
decorator is still a good idea for such a big, brand-new feature, though.
That what it was introduced for.
In this case we have very similar features that we have had for a long
time, in addition to a certain amount of stability with the code. By that,
I think we shouldn't scare users with such a warning.
> > I don't want to diminish their work, but sometimes after having the
code there and looking ahead, major refactoring can be needed. However,
there would likely need to be refactoring of the usual commutative
polynomials to address the issue you brought up. There could also be ways
to factor out common code from other algebras across Sage. So in short,
what I'm suggesting is to have a common abstract base class for both for
the basic/core functionality. If there is only a little overlap (I really
haven't looked), then we can just continue in our current fashion.
>
> I agree that this would be nice and should be looked at. However, can I
suggest
> that this is for another ticket (cf. Reviewer's Checklist ["The perfect
is the enemy of the
good"][http://doc.sagemath.org/html/en/developer/reviewer_checklist.html]).
I'm not asking for perfection. If we do decide to subclass, then it just
makes it somewhat harder to refactor once this is included. Just to be
clear, I am just raising the question, not making the refactoring a
requirement.
> That way, improvements could progress on both ends (improving code
sharing between the polynomial types, while improving skew poly
functionality, and the coding theory constructions that we will build
using skew polynomials).
If only I had time... :P
--
Ticket URL: <https://trac.sagemath.org/ticket/13215#comment:69>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
