#18109: Restructure IntegerListLex code
-------------------------------------+-------------------------------------
Reporter: vdelecroix | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.6
Component: combinatorics | Resolution:
Keywords: | Merged in:
Authors: Jeroen Demeyer | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/jdemeyer/ticket/18109 | 9582a7a5248f609a2d2de02497b4b1d36d9dd96e
Dependencies: #18181, #18184 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by ncohen):
> A main point being: unless we create millions of small IntegerListsLex
> objects, I don't see why having it be a (facade) parent makes things
> slower.
Wouldn't this happen if somebody wants, for all `n` between 10 and 1000,
one instance of a partition of `n` satisfying <a specific set of
constraints> ?
There is a (trivial) case at least which makes sense to me, i.e. for a
fixed `k` find some partition of `n` into integers of size `floor(n/k)`
and `ceil(n/k)`. I agree that this can be done manually without this
iterator, but I expect that it can happen with more complicated set of
constraints too.
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/18109#comment:48>
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.