#18109: IntegerListLex better not be a parent
---------------------------------+------------------------
Reporter: vdelecroix | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.6
Component: combinatorics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
---------------------------------+------------------------
Comment (by ncohen):
> We want to keep the parent to model the set itself, ask questions
> like cardinality or building the polyhedron, do constructions on top
> of it (e.g. use it as indexing set for a vector space), etc.
The 'Lex' there seems a bit too much for the mathematical object that you
want to represent. You describe things that could be a method of an
'IntegerLists' object (or more specifically methods of 'Compositions' or
'Partitions').
> - Being able to specify an element constructor is a useful feature as
> well. What we need to discuss here is whether we want to switch to
> using lists (or tuples!) by default.
There should be a way to enumerate these objects without paying this cost,
however. A way to have both is to implement the iterator to return a copy
of the current list, or a tuple (or even the current list itself, with big
'read only' warnings), and then implement in `IntegerListsLex` an
`__iter__` that wraps every element returned by that iterator with
<whatever you need>.
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/18109#comment:2>
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.
