#13605: Partition options and cleanup partitions documentation
-----------------------------------------------+----------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.6
Component: combinatorics | Resolution:
Keywords: partition, options, output | Work issues:
Report Upstream: N/A | Reviewers: Andew Mathas
Authors: Travis Scrimshaw | Merged in:
Dependencies: #13074 #13762 #13840 #10193 | Stopgaps:
-----------------------------------------------+----------------------------
Comment (by andrew.mathas):
Hi Travis,
Here are some more questions/issues. Consider
{{{
sage: a=Partitions(4)
sage: b=Partitions(4,order='containment')
sage: a
Partitions of the integer 4
sage: b
Partitions of the integer 4
sage: a == b
False
}}}
This is correct, of course, but it is potentially confusing because a and
b look exactly the same when printed, I think that it would be better if
the ordering ordering on the class was returned by ``_repr_``, at least
when the default ordering is not being used. That is, I am suggesting the
following behaviour:
{{{
sage: a=Partitions(4)
sage: b=Partitions(4,order='containment')
sage: a
Partitions of the integer 4
sage: b
Partitions of the integer 4 with the containment ordering
sage: a == b
False
}}}
Continuing this example:
{{{
sage: a[:]
[[4], [3, 1], [2, 2], [2, 1, 1], [1, 1, 1, 1]]
sage: a._list.sort(); a[:]
[[1, 1, 1, 1], [2, 1, 1], [2, 2], [3, 1], [4]]
}}}
This, to me, just looks wrong: the default ordering should correspond to
the order in which the partitions are generated by the iterator. That is,
the default really should be 'rev_lex' or the iterator should change.
A second related issue is that in calling Partitions(4)[:], via a[:], we
have created the list of *all* partitions of 4 BUT b does not know about
this:
{{{
sage: a._list
[[1, 1, 1, 1], [2, 1, 1], [2, 2], [3, 1], [4]]
sage: b._list
Traceback (most recent call last)
...
AttributeError: 'Partitions_n_with_category' object has no attribute
'_list'
}}}
In this particular example this is not important because generating the
list of partitions of 4 is very quick, but if instead we were looking at
the partitions of 50 or 100 then this starts to become an issue.
The reason, of course, is that ``Partitions`` is a subclass of
``UniqueRepresentation`` and ``order`` is an argument to the __init__
method of the class. I think that it would be preferable to make the
"ordered classes" proper subclasses of the ``Partitions`` class with the
default ordering. This way they would all be able to share their _list
attributes so that the list of all partitions in the class would only ever
need to be computed once. This could easily be done inside
Partitions.__classcall_private__.
Another possibility would be to make ``order`` a part of
partition_options. In terms of the code this would be almost trivial as
currently ``order`` is used only inside the comparison methods.
Mathematically, I think that you can argue both ways: it is useful to be
able to use different orderings on the set of partitions so you don't want
an individual partition to be restricted to using a fixed order, on the
other the the poset of partitions with a particular order is a useful
structure.
I think that Nicolas objected to doing it this way on the basis that it
might break code which implicitly assumed a particular order on the
partitions. I don't like this argument as it encourages bad coding: if a
particular ordering is required by the code then this should be explicit
in the code. (Up until now it hasn't been possible to easily change the
ordering being used, but now that it is becoming possible the algorithms
which require a particular ordering should be updated to make this
explicit.)
**I think that moving ``order`` into ``partition_options`` is the best
solution.**
On the other hand, if you think it better to have honestly different
classes for each ordering then I think that the iterator should be
modified to produce the partitions in the correct order. This would be
annoying to do properly but could be done by first constructing the list
of all partitions and then sorting. This is potentially time consuming,
but if some one honestly needs a class for the poset with a particular
order then they probably need all of its elements(?).
Andrew
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13605#comment:13>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
