#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: Anne Schilling,
Report Upstream: N/A | Travis Scrimshaw
Branch: | Work issues:
u/tscrim/refactor_integer_lists_lex-18109| Commit:
Dependencies: #15525 | 2e5e9691da0c2003d7eb3ddcf6c5c5010281f4dc
| Stopgaps:
-------------------------------------+-------------------------------------
Changes (by tscrim):
* reviewer: Travis Scrimshaw => Anne Schilling, Travis Scrimshaw
Comment:
Replying to [comment:87 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 don't need this flexibility, but it comes as an added bonus. Right now
we can check backends explicitly, but this allows us to separate that off
into a completely separate package and still retain a differentiation.
> 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.
I can see both use cases as well, but chances are there will be a coupling
between base classes and backend. However I don't think it is really
useful to continue this discussion because we both have our reasons for
liking it. We just need to take care of the additions from #15525 (and the
doc tweak above). Do you want me to do that (since that was my ticket) or
will you?
--
Ticket URL: <http://trac.sagemath.org/ticket/18109#comment:89>
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.
