Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Travis! On Tue, Oct 30, 2012 at 04:02:08PM -0700, Travis Scrimshaw wrote: > Here's the state of the #13605 patch and what it currently is doing: Thanks for all your hard work! Yippee in particular for long desired things like: >- IntegerListsLex no longer inherits from CombinatorialClass, but instead >from Parent with elements of ClonableArray Have you made some timings to measure the improvement? >- Added partition options which can do French/English, latex outputs, >Ferrers' diagram characters, some ordering Just checking since I haven't followed seriously sage-combinat-devel lately; for the semantic-changing options: +1 on Partitions(order=...) -1 on Partitions().options(order=...) >- Deprecating the following methods and classes: >* evaluation() What is the rationale? >* OrderedPartitions_nk -- Renamed to OrderedPartitions since the >function OrderedPartitions just created this >* ... and all variants ... It is likely that we will eventually have OrderedPartitions() construct the set of all ordered partitions. It would thus be natural to reserve the name OrderedPartitions for the class of this set. >- Changed *_lengths into *_length_tableau() (ex. arm_lengths() becomes >arm_length_tableau() ) and deprecated old names What is the rational? >- Made Partitions_n inherit from Partitions This breaks the "is_a" rule: the set of all partitions of 3 is not an instance of the class Partitions; the (by the way unique) instance of the latter indeed models the set of all partitions. Hmm, I would have expected UniqueRepresentation to bark about this. >- Made the other finite set of partitions inherit from Partitions_n except >those that inherited from IntegerListsLex Idem. >The other 3 are more serious and have to do with docstring >testing. Apparently if a parent class has a category which has a >default implementation of a method, that category's >implementation is what's called, despite if the parent defines >the same function. This is not supposed to happen. Let me know if you manage to narrow down the problem into something reproducible. >Also there are a few questions I want to ask. Tableaux should >also have options (French vs. English in particular), but should >they be linked to the options for Partitions? Same question to >PartitionTuples with Partitions. I propose to start with the options being linked. Indeed, the standard use case will be for someone to always prefer English or always prefer French notation, and there should be a single point of truth for storing this user preference. If later someone really wants distinct conventions for tableaux or partitions, then that person will take on the task to have linked options as a default, with a way to unlink them. Thanks again! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Nicolas, > >- IntegerListsLex no longer inherits from CombinatorialClass, but > instead > >from Parent with elements of ClonableArray > > Have you made some timings to measure the improvement? > No I haven't. I just remove the (deprecated-ish) CombinatorialClass and made sure IntergerListsLex were in the category framework. I'll make some timings tonight/tomorrow. > > >- Added partition options which can do French/English, latex outputs, > >Ferrers' diagram characters, some ordering > > Just checking since I haven't followed seriously sage-combinat-devel > lately; for the semantic-changing options: > > +1 on Partitions(order=...) > -1 on Partitions().options(order=...) > I'm currently planning on changing it to the first way. > > >- Deprecating the following methods and classes: > >* evaluation() > > What is the rationale? > It was from MuPAD-combinat and the name doesn't make sense to me. I don't feel strongly about this, so if you (or anyone else) want to keep it there, I have no objections. > >* OrderedPartitions_nk -- Renamed to OrderedPartitions since the > >function OrderedPartitions just created this > >* ... and all variants ... > > It is likely that we will eventually have OrderedPartitions() > construct the set of all ordered partitions. It would thus be natural > to reserve the name OrderedPartitions for the class of this set. > So then make OrderedPartitions similar to how Partitions is (as a factory class)? > > >- Changed *_lengths into *_length_tableau() (ex. arm_lengths() > becomes > >arm_length_tableau() ) and deprecated old names > > What is the rational? > The output is a tableau (whose entries are the *_lengths) and I believe it is more clear. Again I have no strong opinions. > > >- Made Partitions_n inherit from Partitions > > This breaks the "is_a" rule: the set of all partitions of 3 is not an > instance of the class Partitions; the (by the way unique) instance of > the latter indeed models the set of all partitions. Hmm, I would have > expected UniqueRepresentation to bark about this. > When I said inherit, I meant I made Partitions_n a subclass of Partitions. If we're on the same page with that, then I don't quite see the problem. > >The other 3 are more serious and have to do with docstring > >testing. Apparently if a parent class has a category which has a > >default implementation of a method, that category's > >implementation is what's called, despite if the parent defines > >the same function. > > This is not supposed to happen. Let me know if you manage to narrow > down the problem into something reproducible. If you run sage -t partition.py with the current version of the patch, you'll see this occur (in particular, it doesn't know how to handle the additional arguments). I'll write a small example illustrating this and open a new trac ticket. Thank you, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/JVU6NhjQitoJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Travis! On Fri, Nov 02, 2012 at 07:45:35PM -0700, Travis Scrimshaw wrote: >+1 on Partitions(order=...) >-1 on Partitions().options(order=...) > >I'm currently planning on changing it to the first way. Thanks! > >- Deprecating the following methods and classes: > >* evaluation() > >It was from MuPAD-combinat and the name doesn't make sense to me. I don't >feel strongly about this, so if you (or anyone else) want to keep it >there, I have no objections. Here is the rationale: The *commutative evaluation*, often shortened to *evaluation* of a word is its image in the free commutative monoid. In other words one counts how many occurrences there are of each letter. By extension this definition extends to any word-like object (partitions, ...). And that's exactly what `to_exp` is doing. (and it turns out that for a partition this contains all the information). Granted: there should be an abstract class for word-like objects (or more possibly generally objects with labels), and this method should be implemented there. But in the mean time just leave it there. >So then make OrderedPartitions similar to how Partitions is (as a factory >class)? Precisely. But this can wait as it currently is until we indeed have more than one class to justify the existence of a factory. > >- Changed *_lengths into *_length_tableau() (ex. arm_lengths() > becomes > >arm_length_tableau() ) and deprecated old names > > What is the rational? > >The output is a tableau (whose entries are the *_lengths) and I believe it >is more clear. Again I have no strong opinions. We have that general rule of thumb that one should name the mathematical meaning of the output rather than its data structure. >From my point of view, the output is the lengths of the arms of all the cells; the fact that we use a tableau as data structure to store that information is essentially an implementation detail. Opinions anyone else? > >- Made Partitions_n inherit from Partitions > > This breaks the "is_a" rule: the set of all partitions of 3 is not an > instance of the class Partitions; the (by the way unique) instance of > the latter indeed models the set of all partitions. Hmm, I would have > expected UniqueRepresentation to bark about this. > >When I said inherit, I meant I made Partitions_n a subclass of Partitions. That's also how I interpreted inherit. My point is precisely that making Partitions_n a subclass of Partitions breaks the "is_a" rule. >If you run sage -t partition.py with the current version of the >patch, you'll see this occur (in particular, it doesn't know how >to handle the additional arguments). Ok, I'll try to pull, but there is no guarantee that this will get through. >I'll write a small example illustrating this and open a new trac >ticket. Thanks! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
> Granted: there should be an abstract class for word-like objects (or > more possibly generally objects with labels), and this method should > be implemented there. But in the mean time just leave it there. Note that the terminology is not uniform. Among others * evaluation * Parikh vector * Abelianization * number of occurences of letters * ... see [1] It would be nice that we have a convention for that. Should we put all of .evaluation(), .parikh_vector() and .abelianization() in the namespace of a word-like object ? Which one should be the prefered one ? [1] http://wiki.sagemath.org/LanguagesAndTilings#Parikh_vector.2C_evaluation.2C_abelianization Best, Vincent -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
On Mon, Nov 05, 2012 at 03:15:35PM +0100, Vincent Delecroix wrote: > > Granted: there should be an abstract class for word-like objects (or > > more possibly generally objects with labels), and this method should > > be implemented there. But in the mean time just leave it there. > > Note that the terminology is not uniform. Among others > * evaluation > * Parikh vector > * Abelianization > * number of occurences of letters > * ... > > see [1] > > It would be nice that we have a convention for that. Should we put all > of .evaluation(), .parikh_vector() and .abelianization() in the > namespace of a word-like object ? Which one should be the prefered one > ? Thanks for the pointer. Hmm, let's see. Here are my appreciations of pros and cons: - Parikh vector: sounds too specific to a community; people outside the community won't find it. We want to have variants that don't return the result as a vector. - Evaluation: probably specific to a community (algebraic combinatorics if not Marne-la-vallée). The name does not convey the main information (that we are going to the *commutative* world). It has been around for a long time in MuPAD-Combinat - Abelianization: contains the main information - number of occurences of letters: very explicit but long So altogether I hesitate between evaluation and abelianization, with a preference for the second one but mitigated by the advantage of minimal change :-) Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
On 11/5/12 6:50 AM, Nicolas M. Thiery wrote: > On Mon, Nov 05, 2012 at 03:15:35PM +0100, Vincent Delecroix wrote: >>> Granted: there should be an abstract class for word-like objects (or >>> more possibly generally objects with labels), and this method should >>> be implemented there. But in the mean time just leave it there. >> >> Note that the terminology is not uniform. Among others >> * evaluation >> * Parikh vector >> * Abelianization >> * number of occurences of letters >> * ... >> >> see [1] >> >> It would be nice that we have a convention for that. Should we put all >> of .evaluation(), .parikh_vector() and .abelianization() in the >> namespace of a word-like object ? Which one should be the prefered one >> ? > > Thanks for the pointer. Hmm, let's see. Here are my appreciations of > pros and cons: > > - Parikh vector: sounds too specific to a community; people outside > the community won't find it. We want to have variants that don't > return the result as a vector. > > - Evaluation: probably specific to a community (algebraic > combinatorics if not Marne-la-vallée). The name does not convey the > main information (that we are going to the *commutative* world). It > has been around for a long time in MuPAD-Combinat > > - Abelianization: contains the main information > > - number of occurences of letters: very explicit but long > > So altogether I hesitate between evaluation and abelianization, with a > preference for the second one but mitigated by the advantage of > minimal change :-) evaluation is very common in tableaux combinatorics. Best, Anne -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey everyone, Just checking since I haven't followed seriously sage-combinat-devel > lately; for the semantic-changing options: > > +1 on Partitions(order=...) > -1 on Partitions().options(order=...) > For doing the ordering option, how do we want to compare two elements with different ordering on parents? In particular if we do ordering using the left argument, we'd have (this is not yet in the queue): sage: P = Partitions(order="lex")([3, 3]) sage: Q = Partitions(order="dominance")([4, 1, 1]) sage: P < Q True # if compared with lex sage: Q > P False # if compared with dominance Should we just return False in both cases or default back to lex ordering? The easiest option seems to be is leave it as is, where everything using comparison operators is lex and to check dominance, you call P.dominate(Q) with large amounts of documentation and warnings about this. Thoughts? Thanks, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/cok5dxDacBkJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
On Thu, Nov 08, 2012 at 10:04:17AM -0800, Travis Scrimshaw wrote: > For doing the ordering option, how do we want to compare two elements >with different ordering on parents? In particular if we do ordering using >the left argument, we'd have (this is not yet in the queue): > sage: P = Partitions(order="lex")([3, 3]) > sage: Q = Partitions(order="dominance")([4, 1, 1]) > sage: P < Q > True # if compared with lex > sage: Q > P > False # if compared with dominance > Should we just return False in both cases or default back to lex >ordering? The easiest option seems to be is leave it as is, where >everything using comparison operators is lex and to check dominance, you >call P.dominate(Q) with large amounts of documentation and warnings about >this. Thoughts? If it was just for me, I would forbid to compare with '<' two objects with different parents (possibly with some well chosen exceptions like 1/2 < 1). In other words: if you get into a situation where you have a serious doubt about the semantic (and thus probably even more so for the caller), I vote for just raising an exception. That's the safest. Thoughts anyone else? Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi! Florent's patch partition_leg_length_speedup-fh.patch no longer applies over trac_13605-partition_options-ts.patch. The relevant change is just to the format of a raise ValueError, so it would be easy enough either not to make the change in 13605, or to rebase Florent's patch. cheers, Hugh On Thursday, November 8, 2012 10:25:42 AM UTC-8, Nicolas M. Thiery wrote: > > On Thu, Nov 08, 2012 at 10:04:17AM -0800, Travis Scrimshaw wrote: > > For doing the ordering option, how do we want to compare two > elements > >with different ordering on parents? In particular if we do ordering > using > >the left argument, we'd have (this is not yet in the queue): > > sage: P = Partitions(order="lex")([3, 3]) > > sage: Q = Partitions(order="dominance")([4, 1, 1]) > > sage: P < Q > > True # if compared with lex > > sage: Q > P > > False # if compared with dominance > > Should we just return False in both cases or default back to lex > >ordering? The easiest option seems to be is leave it as is, where > >everything using comparison operators is lex and to check dominance, > you > >call P.dominate(Q) with large amounts of documentation and warnings > about > >this. Thoughts? > > If it was just for me, I would forbid to compare with '<' two objects > with different parents (possibly with some well chosen exceptions like > 1/2 < 1). > > In other words: if you get into a situation where you have a serious > doubt about the semantic (and thus probably even more so for the > caller), I vote for just raising an exception. That's the safest. > > Thoughts anyone else? > > Cheers, > Nicolas > -- > Nicolas M. Thi�ry "Isil" > > http://Nicolas.Thiery.name/ > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/psTugEibIkMJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Travis-- Also, you seem to have incorporated the (unique, small) change from partition_speedup_jb.patch, so it doesn't apply either. cheers, Hugh -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/S3UhtLRpKXkJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi! tableaux-combinatorics-am.patch needs to be rebased on top of Travis's patch trac_13605-partition_options-ts.patch. (Andrew's patch edits some doctests that Travis has removed, and there are some changes to import statements -- nothing looks very complicated.) cheers, Hugh -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/_TD2JHTQhmAJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Hugh, Florent, and Andrew, - I rebased the partition_leg_speedup-fh.patch since noone has seems to have touched it in awhile and I making partitions.py Python 3 compliant. - I disabled partitions_speedup_jb.patch since I wanted to ask if it is okay that I remove this since I ended up incorporating the changes? (I can also incorporate the leg_speedup too if desired.) - Andrew, do you want me to rebase your patch, and every subsequent time I push any changes to the partition options patch? 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... Thanks, Travis On Friday, November 9, 2012 9:55:17 AM UTC-8, Hugh Thomas wrote: > > > Hi! > > tableaux-combinatorics-am.patch needs to be rebased on top of Travis's > patch trac_13605-partition_options-ts.patch. (Andrew's patch edits some > doctests that Travis has removed, and there are some changes to import > statements -- nothing looks very complicated.) > > cheers, > > Hugh > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/_fEhqFzP4i0J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Nicolas, If it was just for me, I would forbid to compare with '<' two objects > with different parents (possibly with some well chosen exceptions like > 1/2 < 1). > > In other words: if you get into a situation where you have a serious > doubt about the semantic (and thus probably even more so for the > caller), I vote for just raising an exception. That's the safest. > > Thoughts anyone else? > The more I think about it and how to implement it, the more I feel like we should just leave the ordering alone (but add more documentation and warnings) considering that we should keep comparisons with lists (which default to lex ordering since it upcalls to CombinatorialObject's comparisons) and having to keep track of which comparison actually gets called for consistency (i.e. order matters). If that doesn't make sense, I can put up an example later tonight. 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... Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/PcoftGMPxlwJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi--
The patch kshape-om.py now produces an import error at Sage startup
("cannot import name Partition_class"). I'm guessing this has to do with
Travis's work on partitions.
I have disabled it for now.
cheers,
Hugh
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/xq1Yq771PqkJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
> The patch kshape-om.py now produces an import error at Sage startup
> ("cannot import name Partition_class"). I'm guessing this has to do with
> Travis's work on partitions.
>
Yes, it's because kshape.py imports Partition_class rather than Partition.
I've rebased my patch and uploadded it.
A.
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/7WAgFIsVUhwJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
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... Agreed ... Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
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... This could be a good candidate for a lazy_import. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Nicolas, This could be a good candidate for a lazy_import. > > I'll give it a try. Hey Hugh, What Andrew said was correct, it's because we are removing Partition_class. I will setup an alias with a deprecation warning. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/y_kDwSBcc2gJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Thanks, Travis and Andrew, for the rebasing and the explanations. cheers, Hugh -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/Sc6RpTfMtYsJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Hugh, No problem. Sorry this has been such a hassle. Also, I've rebased concrete_combinatorial_statistics_and_maps-cs.patch (with Christian's approval), so the whole queue should (at present) apply cleanly. Best, Travis On Sunday, November 11, 2012 11:54:20 PM UTC-8, Hugh Thomas wrote: > > > Thanks, Travis and Andrew, for the rebasing and the explanations. > > cheers, > > Hugh > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/6Sk_rF0rYRkJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Travis, You should probably also deprecate sage.combinat.partition.Partitions_all_cache. Currently, this causing issues for skew_partition.py which calls this once. Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/0cQVB3MjgtoJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi! FYI, further rebasing of tableaux-combinatorics-am.patch seems to be needed. I'm going to disable it temporarily so the queue applies. cheers, Hugh -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/gQVugDxP2WcJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
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. Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/HhtsChmnBVoJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Thanks Andrew! Travis 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. > > Andrew > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/TVTjmgL7RfkJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
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
def __lt__(self, other):
return other > self
}}}
Thoughts?
Thanks,
Travis
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/wuC--jwgynUJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Travis, 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? Cheers, Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/wjZucoM2tB8J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Andrew and Travis, > 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. Best, Anne -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
> 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. Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/jRCWedLaWS8J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Andrew, > > 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. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/CF7uQbxOcTcJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
>
> 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...
Andrew
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/YN8MMBbDsgsJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hey Andrew,
> 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...
>
I might have just made that up...
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/hgCNr_M-Pj4J.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
> 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. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/Igg_-FODdcAJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Andrew, 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 See e.g.: http://www.sagemath.org/doc/reference/sage/rings/polynomial/term_order.html Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
