On Fri, Nov 09, 2012 at 05:49:47PM -0800, Travis Scrimshaw wrote:
> In all honesty, I almost feel like any comparison should do a coercion
> into a common parent and check there, and if not possible, then raise an
> exception. However this is likely to be a major overhaul and break a few
> (a lot) of things...
On Fri, Nov 09, 2012 at 10:35:34AM -0800, Travis Scrimshaw wrote:
> In cleaning up the import statements (in my definition of cleanup, and
> if I shouldn't touch import statements, please let me know), I noticed an
> interesting quirk, partition.py needs to import skew_partition.py,
> otherwise there's an import error on startup...
You should probably also deprecate sage.combinat.partition.Partitions_all_cache. Currently, this causing issues for skew_partition.py which calls this once.
Also in regard to the partition options patch, I can't seem to find the Partitions_all_cache when the queue is applied up to there (I'm running 5.4.beta1).
Hi Travis,
I had a look at the patch queue and Partitions_all_cache was added by partition_constructor_speedup-fh.patch which was recently disabled. Partitions_all_cache is needed, however, by the skew_partitions_init_speedup-fh.patch. So I have disabled the skew partitions speed-up patch as well. Sage now builds when all of the queue is applied.
On Tuesday, November 13, 2012 4:29:37 PM UTC-8, Andrew Mathas wrote:
> On 14/11/12 6:24 AM, Travis Scrimshaw wrote:
> Also in regard to the partition options patch, I can't seem to find the > Partitions_all_cache when the queue is applied up to there (I'm running > 5.4.beta1).
> Hi Travis,
> I had a look at the patch queue and Partitions_all_cache was added by > partition_constructor_speedup-fh.patch which was recently disabled. > Partitions_all_cache is needed, however, by the > skew_partitions_init_speedup-fh.patch. So I have disabled the skew > partitions speed-up patch as well. Sage now builds when all of the queue is > applied.
Hey everyone, Here's the current update of the options patch #13605:
- I've added "containment" as an additional order option which are set in the parent objects
- I've had to leave `Partitions_all` alone for the most part, deprecating it caused pickling/TestSuite errors I couldn't figure out how to fix
- Undeprecated the `*lengths()` and removed the `*length_tableau()` functions
- Undeprecated `evaluation()` and elaborated its docstrings
- Added tableau options and integrated with `TableauTuple`
- Added a method (I believe I called it `larger_lex()` which compares lex)
- More doc tweaks
- Deprecated the `from_*` from the module level and are now directly callable as `Partitions().from_*`.
Right now there's still about a million doctests to fix (primarily in symmetric functions because by implementing the comparison operators for partitions, it has changed the ordering of the terms), but I wanted to make sure everyone is okay with the current functionality of the patch before I start making all doctests pass.
However there is one other thing I wanted to ask, and that is instead of passing in a string for a particular ordering, pass in a function which compares greater than and base all other comparisons off that? Something like this for example: {{{ class Foo: def __init__(self, order=None): if order is not None: self.__gt__ = order
def __ge__(self, other): if self == other or self > other: return True return False
I have twos questions about the order options that have appeared in your partition clean-ups.
The easy one first: should the reverse ordering also exist? That is, "reverse lex", "reverse dominance", "reverse containment"? If people agree that it is worth including these explicitly it would be good if there was a systematic way to organise all of the orderings...will let you know if I come up with something.
The second question is harder: is it intended that, ultimately, the order in which the partitions are generated by the iterator will be compatible with the order on the parent? If the ordering is part of the parent then I think that this is a reasonable expectation but, of course, it would be painful implement.
What do people think is the "ideal" way this should work for any parent that comes equipped with an (optionable) ordering?
> The easy one first: should the reverse ordering also exist? That is, "reverse lex", "reverse dominance", "reverse containment"? If people agree that it is worth including these explicitly it would be
> good if there was a systematic way to organise all of the orderings...will let you know if I come up with something.
Yes, I think this is reasonable!
> The second question is harder: is it intended that, ultimately, the order in which the partitions are generated by the iterator will be compatible with the order on the parent? If the ordering is part
> of the parent then I think that this is a reasonable expectation but, of course, it would be painful implement.
> What do people think is the "ideal" way this should work for any parent that comes equipped with an (optionable) ordering?
Basically you would like the iterator to return a linear extension of the
ordering? That might be possible if by considering the poset given by
the partial order.
> Basically you would like the iterator to return a linear extension of the > ordering? That might be possible if by considering the poset given by > the partial order.
> Yes, that's right. This is most sensible for total orderings, but for
partial orders the iterator could return a non-canonical (and presumably not completely guaranteed) linear extension.
I think that this would be a useful feature, unfortunately, to do it efficiently would probably require separate iterators for each ordering. Throwing efficiency to the wind, you could of course generate any FiniteEnumerateSet component and then sort this using the already implemented comparision methods.
> The easy one first: should the reverse ordering also exist? That is, > "reverse lex", "reverse dominance", "reverse containment"? If people agree > that it is worth including these explicitly it would be good if there was a > systematic way to organise all of the orderings...will let you know if I > come up with something.
I will do "reverse lex" (lex order read from right to left) and "reverse dominance" (which I presume is partial sums from right to left). However what is reverse containment?
> The second question is harder: is it intended that, ultimately, the order > in which the partitions are generated by the iterator will be compatible > with the order on the parent? If the ordering is part of the parent then I > think that this is a reasonable expectation but, of course, it would be > painful implement.
For lex and dominance, I believe this shouldn't be a problem. Containment is slightly tricky, but I doubt its too horrible. The true problems might be with the reverse orderings, and that we might have to do something more complex.
> I will do "reverse lex" (lex order read from right to left) and "reverse > dominance" (which I presume is partial sums from right to left). However > what is reverse containment?
AH, I guess that "reverse lexicographic" is ambiguous as it could mean either reading the words in the reverse order or simply reversing the partial order.
For me, and what I meant with all of these orderings, is simply taking the same order but in the reverse order: x \le_{rev} y <==> y \le x Of course, this is a very trivial difference but it is still a significant one in terms of the poset and the order in which the partitions are generated. In my work, the "reverse" orderings in this sense play a very important role: they reflect contragredient duality and also the duality arising from tensoring with the sign representations.
I have never seen an application of the "right to left" lexicographic ordering, although I have this vague feeling that it appears in Stanley's book (but then, so do most things!:). I don't remember ever seeing the right to left dominance order...
> I will do "reverse lex" (lex order read from right to left) and "reverse >> dominance" (which I presume is partial sums from right to left). However >> what is reverse containment?
> AH, I guess that "reverse lexicographic" is ambiguous as it could mean > either reading the words in the reverse order or simply reversing the > partial order.
> For me, and what I meant with all of these orderings, is simply taking the > same order but in the reverse order: > x \le_{rev} y <==> y \le x > Of course, this is a very trivial difference but it is still a significant > one in terms of the poset and the order in which the partitions are > generated. In my work, the "reverse" orderings in this sense play a very > important role: they reflect contragredient duality and also the duality > arising from tensoring with the sign representations.
Ah I see. I will implement a (naive) __reversed__() method for the partitions (see http://docs.python.org/2/library/functions.html#reversed) since we've removed __len__() from the partition parents. That way you can just call `reversed(Partitions(5))` to iterate through in reverse. Expect it on the next #13605 push.
> I have never seen an application of the "right to left" lexicographic > ordering, although I have this vague feeling that it appears in Stanley's > book (but then, so do most things!:).
I've seen it, although it was in the context of simplicial complexes.
> I don't remember ever seeing the right to left dominance order...
> Ah I see. I will implement a (naive) __reversed__() method for the > partitions (see http://docs.python.org/2/library/functions.html#reversed) > since we've removed __len__() from the partition parents. That way you can > just call `reversed(Partitions(5))` to iterate through in reverse. Expect > it on the next #13605 push.
Done and pushed.
> I have never seen an application of the "right to left" lexicographic >> ordering, although I have this vague feeling that it appears in Stanley's >> book (but then, so do most things!:).
> I've seen it, although it was in the context of simplicial complexes.
I've added it in case someone has an application for it. I will add more warnings about our convention between lex and rev lex orderings.
On Tue, Dec 11, 2012 at 01:31:28AM -0800, Andrew Mathas wrote:
> AH, I guess that "reverse lexicographic" is ambiguous as it could mean
> either reading the words in the reverse order or simply reversing the
> partial order.
FWIW, In commutative algebra, and about term orders, they often use:
inverse lexicographic (read the word right to left)
negative lexicographic (reversing the partial order)
reverse lexicographic == negative inverse lexicographic
