#18109: Restructure IntegerListLex code
-------------------------------------+-------------------------------------
Reporter: vdelecroix | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.10
Component: combinatorics | Resolution:
Keywords: | Merged in:
Authors: Jeroen Demeyer | Reviewers: Travis Scrimshaw
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/tscrim/refactor_integer_lists_lex-18109|
2e5e9691da0c2003d7eb3ddcf6c5c5010281f4dc
Dependencies: #15525 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by jdemeyer):
Replying to [comment:85 tscrim]:
> In writing this comment, I've convinced myself that having a frontend
class for each backend will likely be a good thing in practice as it can
be used to distinguish different iteration orders without having to look
at the backend
But why would you need to "distinguish different iteration orders" in the
first place?
In the few cases (maybe invlex is the only one?) where the iteration
algorithm really matters, I understand that you want a separate front-end.
However, it should be possible for a backend to iterate in an arbitrary
order.
I really want to see the front-end and back-end as orthogonal: I can see
use cases for different front-ends with the same back-end and use cases
for different back-ends for the same front-end.
--
Ticket URL: <http://trac.sagemath.org/ticket/18109#comment:87>
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.
