[sage-combinat-devel] Re: number_of_partitions and friends
Did you make a quick benchmark on Partitions().random_element(), with and without caching? Given that number_of_partitions (which was already fast) was even further optimized recently, maybe caching is not relevant anymore? Hi Nicolas, I have just noticed that Trac #13199 http://trac.sagemath.org/sage_trac/ticket/13199implements a new version of number_of_partitions using flint. Was this the recent optimisation that you were referring to? I was using Bober's implementation. 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/-/XrXukBJqR-EJ. 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] Re: number_of_partitions and friends
On Wed, Aug 29, 2012 at 08:32:11PM -0700, Andrew Mathas wrote: Then I think the functionality of RestrictedPartitions should be fully implemented in Partitions by allowing several keyword entries. I had a look at the code and there doesn't seem to be an obvious quick fix because the classes determined by parts_in and max_length and friends are generated in different ways. Preumably this is why it is not currently possible to combine them. There is one rick which might work so I'll have a play with this when I have time. I guess that we need an IntersectionEnumeratedSets category:) That sounds fine to me. I think that RestrictedPartitions should not be removed until this happens. This could be addressed at #12278 or at #13072. If I can't think of a way of giving this functionality I'll leave these classes alone for now, and update the ticket on #12278. +1 Algorithmically speaking, a proper reimplementation for RestrictedPartitions should probably be done using species; as for mixed keyword entries, I guess we won't have much better than filtering. From a design perspective, the handling of mixed keywords would be best implemented at the occasion of the refactoring of Partitions using Florent's enumerated sets factories. (see http://trac.sagemath.org/sage_trac/ticket/10194). Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
[sage-combinat-devel] Re: number_of_partitions and friends
Hi Andrew! On Tue, Aug 28, 2012 at 09:50:31PM -0700, Andrew Mathas wrote: I have just pushed a new version of my partition tuple patch #13072 to the combinat queue which addresses the deprecation issues flagged by Nicolas and others. As there are many functions involved I thought I should post a summary of the functions affected so that the few people in the universe who care can check to see whether what I have done is sensible. Thanks for this very thorough summary! In case you haven't done so yet, please copy it in the ticket description as this is very synthetic. +1 on everything. 2. For use in Partitions().random_element() the function number_of_partitions() was cached. This cached function was almost never used so, assuming that caching this function is a good idea, I decided to cache sage.combinat.partitions.number_of_partitions() always. Please let me know if this is a bad idea. Did you make a quick benchmark on Partitions().random_element(), with and without caching? Given that number_of_partitions (which was already fast) was even further optimized recently, maybe caching is not relevant anymore? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
[sage-combinat-devel] Re: number_of_partitions and friends
Did you make a quick benchmark on Partitions().random_element(), with and without caching? Given that number_of_partitions (which was already fast) was even further optimized recently, maybe caching is not relevant anymore? From the remark in partition.py, I think that whoever cached number_of_partitions initially must have done this. I just checked now and the speed when the function is cached is quite dramatic: The following timings show that there is a dramatic speed-up when number_of_partitions is cached: *With caching* sage: %timeit [Partitions(n).random_element() for n in range(100)] 25 loops, best of 3: 25 ms per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 25 loops, best of 3: 24.6 ms per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 25 loops, best of 3: 25.4 ms per loop *Without caching* sage: %timeit [Partitions(n).random_element() for n in range(100)] 5 loops, best of 3: 1.23 s per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 5 loops, best of 3: 1.23 s per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 5 loops, best of 3: 1.26 s per loop I have added all of this to the trac ticket. 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/-/HQYl08bMYYYJ. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
On Wed, Aug 29, 2012 at 05:34:36AM -0700, Andrew Mathas wrote: Did you make a quick benchmark on Partitions().random_element(), with and without caching? Given that number_of_partitions (which was already fast) was even further optimized recently, maybe caching is not relevant anymore? From the remark in partition.py, I think that whoever cached number_of_partitions initially must have done this. I just checked now and the speed when the function is cached is quite dramatic: Ok! Thanks for the updated benchmark. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
[sage-combinat-devel] Re: number_of_partitions and friends
John Palmieri has made the follow remark on trac: Regarding RestrictedPartitions: see #12278http://trac.sagemath.org/sage_trac/ticket/12278. Should it be deprecated at all? In particular, what's the replacement for something like RestrictedPartitions(5,[3,2,1], 3)? The best I can come up with is [p for p in Partitions(5, parts_in=[3,2,1]) if len(p) == 3] but surely this isn't ideal. As John says, currently #13072 removes restricted partitions entirely because these functions/classed were marked for deprecation two or three years ago. This was before I had ever looked at sage and I assumed that this discussion had already been had and that it has already been decided that these classes were not required. I am happy to reinstate RestrictedPartitions if people need them. Please let me know. As an aside, from the point of modular representation theory the name of these functions is unfortunate as for any one working with symmetric groups a p-restricted partition is a partition for which the difference of its consecutive pars is always strictly less than p. These partitions index the irreducible representations of the symmetric group in characteristic p and, more generally, the irreducible representations of the Hecke algebra of the symmetric group at a pth root of unity (for p any positive integer). More generally, there are p-restricted weights in Lie theory. 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/-/2AIhN3cQzZIJ. 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] Re: number_of_partitions and friends
In principle, reading the documentation of Partitions the command sage: RestrictedPartitions(5,[3,2,1], 3).list() [[3, 1, 1], [2, 2, 1]] should be achieved by sage: Partitions(5, parts_in = [3,2,1], max_length=3) Partitions of the integer 5 with parts in [1, 2, 3] but unfortunately max_length is not taken into account: sage: Partitions(5, parts_in = [3,2,1], max_length=3).list() [[3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]] Is this a bug? Best, Anne On 8/29/12 3:45 PM, Andrew Mathas wrote: John Palmieri has made the follow remark on trac: Regarding RestrictedPartitions: see #12278 http://trac.sagemath.org/sage_trac/ticket/12278. Should it be deprecated at all? In particular, what's the replacement for something like RestrictedPartitions(5,[3,2,1], 3)? The best I can come up with is [p for p in Partitions(5, parts_in=[3,2,1]) if len(p) == 3] but surely this isn't ideal. As John says, currently #13072 removes restricted partitions entirely because these functions/classed were marked for deprecation two or three years ago. This was before I had ever looked at sage and I assumed that this discussion had already been had and that it has already been decided that these classes were not required. I am happy to reinstate RestrictedPartitions if people need them. Please let me know. As an aside, from the point of modular representation theory the name of these functions is unfortunate as for any one working with symmetric groups a p-restricted partition is a partition for which the difference of its consecutive pars is always strictly less than p. These partitions index the irreducible representations of the symmetric group in characteristic p and, more generally, the irreducible representations of the Hecke algebra of the symmetric group at a pth root of unity (for p any positive integer). More generally, there are p-restricted weights in Lie theory. Andrew -- 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] Re: number_of_partitions and friends
On Wednesday, August 29, 2012 4:53:33 PM UTC-7, Anne Schilling wrote: In principle, reading the documentation of Partitions the command sage: RestrictedPartitions(5,[3,2,1], 3).list() [[3, 1, 1], [2, 2, 1]] should be achieved by sage: Partitions(5, parts_in = [3,2,1], max_length=3) Partitions of the integer 5 with parts in [1, 2, 3] but unfortunately max_length is not taken into account: sage: Partitions(5, parts_in = [3,2,1], max_length=3).list() [[3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]] Is this a bug? The documentation for Partitions says Right now, the parts_in, starting, and ending keyword arguments are mutually exclusive, both of each other and of other keyword arguments. If you specify, say, parts_in, all other keyword arguments will be ignored; starting and ending work the same way. So it's not a bug: it's documented. (Not ideal behavior, I think, but at least it's documented.) -- John -- 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/-/HvSrQi6Wn4kJ. 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] Re: number_of_partitions and friends
On 8/29/12 5:11 PM, John H Palmieri wrote: On Wednesday, August 29, 2012 4:53:33 PM UTC-7, Anne Schilling wrote: In principle, reading the documentation of Partitions the command sage: RestrictedPartitions(5,[3,2,1], 3).list() [[3, 1, 1], [2, 2, 1]] should be achieved by sage: Partitions(5, parts_in = [3,2,1], max_length=3) Partitions of the integer 5 with parts in [1, 2, 3] but unfortunately max_length is not taken into account: sage: Partitions(5, parts_in = [3,2,1], max_length=3).list() [[3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]] Is this a bug? The documentation for Partitions says Right now, the parts_in, starting, and ending keyword arguments are mutually exclusive, both of each other and of other keyword arguments. If you specify, say, parts_in, all other keyword arguments will be ignored; starting and ending work the same way. So it's not a bug: it's documented. (Not ideal behavior, I think, but at least it's documented.) Then I think the functionality of RestrictedPartitions should be fully implemented in Partitions by allowing several keyword entries. 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] Re: number_of_partitions and friends
On Wednesday, August 29, 2012 5:21:31 PM UTC-7, Anne Schilling wrote: On 8/29/12 5:11 PM, John H Palmieri wrote: On Wednesday, August 29, 2012 4:53:33 PM UTC-7, Anne Schilling wrote: In principle, reading the documentation of Partitions the command sage: RestrictedPartitions(5,[3,2,1], 3).list() [[3, 1, 1], [2, 2, 1]] should be achieved by sage: Partitions(5, parts_in = [3,2,1], max_length=3) Partitions of the integer 5 with parts in [1, 2, 3] but unfortunately max_length is not taken into account: sage: Partitions(5, parts_in = [3,2,1], max_length=3).list() [[3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]] Is this a bug? The documentation for Partitions says Right now, the parts_in, starting, and ending keyword arguments are mutually exclusive, both of each other and of other keyword arguments. If you specify, say, parts_in, all other keyword arguments will be ignored; starting and ending work the same way. So it's not a bug: it's documented. (Not ideal behavior, I think, but at least it's documented.) Then I think the functionality of RestrictedPartitions should be fully implemented in Partitions by allowing several keyword entries. That sounds fine to me. I think that RestrictedPartitions should not be removed until this happens. This could be addressed at #12278 or at #13072. -- John -- 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/-/jB_VJnwfYPIJ. 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] Re: number_of_partitions and friends
Then I think the functionality of RestrictedPartitions should be fully implemented in Partitions by allowing several keyword entries. I had a look at the code and there doesn't seem to be an obvious quick fix because the classes determined by parts_in and max_length and friends are generated in different ways. Preumably this is why it is not currently possible to combine them. There is one rick which might work so I'll have a play with this when I have time. I guess that we need an IntersectionEnumeratedSets category:) That sounds fine to me. I think that RestrictedPartitions should not be removed until this happens. This could be addressed at #12278 or at #13072. If I can't think of a way of giving this functionality I'll leave these classes alone for now, and update the ticket on #12278. 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/-/0ogKX-PWVcQJ. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
I have just pushed a new version of my partition tuple patch #13072 to the combinat queue which addresses the deprecation issues flagged by Nicolas and others. As there are many functions involved I thought I should post a summary of the functions affected so that the few people in the universe who care can check to see whether what I have done is sensible. The list below is in order of what I think is decreasing controversy. 1. A=sage.combinat.partition.number_of_partitions() is marked for deprecation in favour of B=sage.combinat.partitions.number_of_partitions(), which is what function A() calls most of the time. As agreed above, number_of_partitions() will stay in the global name space, but this made the deprecation somewhat fiddly as I did not want to deprecate number_of_partitions() for normal use because from the user perspective this function will not change. Instead, I have deprecated the individual options of number_of_partitions() so deprecation warnings are only generated when A() does NOT call B(). In the global namespace, number_of_partitions still points to A(). When the functions which are marked for deprecation below are removed, number_of_partitions() should be changed to point to B() and A() should be changed into a deprecated_function_alias to B(). See the patch for more details. 2. For use in Partitions().random_element() the function number_of_partitions() was cached. This cached function was almost never used so, assuming that caching this function is a good idea, I decided to cache sage.combinat.partitions.number_of_partitions() always. Please let me know if this is a bad idea. 3. The two functions - cyclic_permutations_of_partition - cyclic_permutations_of_partition_iterator are deprecated in sage.combinat.partition and they have been moved to sage.combinat.set_partition and renamed _of_set_partition... As far as I can tell these functions are never used but, in any case, they are methods on set partitions rather than partitions. Nonetheless, they need to be deprecated from the global name space. 4. The following functions were marked for deprecation several years ago so they have been removed from sage.combinat.partition.py: - RestrictedPartitions - partitions_list - number_of_partitions_list - partitions_restricted - number_of_partitions_restricted 5. The following functions now give deprecation warnings and are marked for removal from the global name space: - partitions_set - number_of_partitions_set - ordered_partitions - number_of_ordered_partitions - partitions, - ferrers_diagram - partitions_greatest - partitions_greatest_eq - partitions_tuples - number_of_partitions_tuples - partition_power In all cases, these function are deprecated in favour of (methods in) parent classes. I also removed Nicolas' temporary patch trac_13072-tuples-of-partitions_number_of_partitions-nt.patchhttp://combinat.sagemath.org/patches/rev/63e7c7e0183dfrom the queue. 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/-/mcM6TNsvPPMJ. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
On Thu, Aug 23, 2012 at 04:48:31PM -0700, Andrew Mathas wrote: Here, I think, is the complete list together with their recommended replacements: Thanks! If no one has complained in, say, two days, please go ahead. Looking again at the code, the function cyclic_permutations_of_partition should probably also become a method of Partitions() but I didn't do this (yet?). +1 Actually, this argument is not so compelling because the default way of computing the number of partitions is to call the cython function sage.combinat.partitions.number_of_partitions If speed is really an issue then people should be calling this directly. In actual fact, the current implementation of partition.number_of_partitions creates extra overhead with some argument parsing. Ultimately, the function either calls the cython code or it calls gap's NrPartitions(), if the number of parts are specified, or there is another option for using pari. I think that it would be better to deprecate partitions.number_of_partitions in favour of the cython code. +1! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
[sage-combinat-devel] Re: number_of_partitions and friends
Hey Andrew,
I have no complaints. I've put myself down as the reviewer on the trac
ticket, so let me know when the patch is ready for a review.
Best,
Travis
On Thursday, August 23, 2012 5:11:03 PM UTC-7, Andrew Mathas wrote:
I remembered that I did in fact discuss doing these deprecations on
sage-combinat when I said that I wanted to implement a functional partition
tuple class last year; see
https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/NFNRYjqoouM
Specifically, I proposed to:
3. Depreciate the following functions/classes in partition.py:
deprecation('partitions_set()
is deprecated. Use the
SetPartitions(S,k) instead')
deprecation('number_of_partitions_set() is deprecated. Use the
SetPartitions(S,k).cardinality() instead')
deprecation('number_of_partitions() is deprecated. Use the
Partitions(n).cardinality() or Compositions(n,k).cardinality()
instead')
deprecation('partitions() is deprecated. Use the iterator from
Partitions() instead')
deprecation('ordered_partitions() is deprecated. Use the
Compositions() instead')
deprecation('number_of_ordered_partitions() is deprecated. Use
the Compositions().cardinality() instead')
deprecation('partitions_greatest() is deprecated. Use
PartitionsGreatestLE(n,k).list() instead')
deprecation('partitions_greatest_eq() is deprecated. Use
PartitionsGreatestEQ(n,k).list() instead')
deprecation('partitions_tuples() is deprecated. Use
Multipartitions(n,k).list() instead')
deprecation('number_of__partition_tulpes() is deprecated. Use
Multipartitions(n,k).cardinality() instead')
deprecation('power_partition() is deprecated. Use
Partition(pi).power(k) instead')
4. Remove all of the code in partition.py that was depreciated in
2009.
At the time no one disagreed with the proposal although, as now, people
were not exactly clamouring for it to happen either:)
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/-/xP0u3oZSkGkJ.
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.
[sage-combinat-devel] Re: number_of_partitions and friends
On Friday, August 24, 2012 12:29:06 AM UTC-7, Nicolas M. Thiery wrote: On Thu, Aug 23, 2012 at 04:48:31PM -0700, Andrew Mathas wrote: Here, I think, is the complete list together with their recommended replacements: Thanks! If no one has complained in, say, two days, please go ahead. I don't think it's a good idea to remove functions from the global name space with no warning. If they were already deprecated, sure, but if not: deprecate them now, and remove them from the global name space in 6 months or a year. I remember seeing number_of_partitions used in some Sage demo talks, for example at least one talk by William Stein, so removing it seems dangerous to me. -- John -- 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/-/wolUPUUbR4QJ. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
Hi Nicolas, I have to confess that I didn't really appreciate that I was deprecating these functions from the global name space but in any case I am in favour of doing so, so +1. Patch #13072 deprecates such functions in favour of the cardinality method of the corresponding partition class. The patch also removes many functions, like partitions_list, which were deprecated a long time ago and so shouldn't be in use any more -- this seems to be the problem that posets/poset_examples.py is having. In fact, many of the functions that #13072 removes were deprecated just in the doc strings, which probably means that they were deprecated well before the now deprecated initial deprecation framework was put in place! Consequently, their flagged deprecation didn't show up when the code was tested. Apologies for not asking everyone if they liked this idea...I thought that these were obvious clean ups that had to happen, and that everyone would just agree...I guess that I am too used to developing my own code in isolation. Sorry! If everyone agrees that this is a good idea then I will add deprecation warnings into sage.combinat.all. If the we vote to keep them then I'll reinstate the global names in the patch. In terms of the functions in doctests etc the best fix would be to change them so that use Partition(n).cardinality() etc. Again, I would hunt these down and fix them if people are in favour of deprecation. By the way, number_of_partitions is one of the few such functions that I didn't deprecate in partition.py. The reason for this is that this function is wrapped in a cached_function call and I didn't want to break this... I suspect that if simply put a cached_method decorator on Partition.cardinality() then this would have the same effect but as I wasn't sure I left it well enough alone. Is this true? Best regards, Andrew On Thursday, 23 August 2012 20:11:57 UTC+10, Nicolas M. Thiery wrote: Hi Andrew, I just noticed that with your patch trac_13072-tuples-of-partitions_am.patch quite a few functions, like ``number_of_partitions`` are not imported by default any more in the interpreter name space. On the principle, I personally like this, as it goes toward having a single entry point for features about partitions (namely Partitions), which reduces the pollution of the interpreter name space. But others may like those shortcuts. So please vote your preference here: [ ] Do not import number_of_partitions and friends any more [ ] Keep things as they currently are in Sage Now, if we indeed go for not importing number_of_partitions, we probably need to deprecate this import, using something like: in sage.combinat.partitions: def number_of_partitions_deprecated(n): ... deprecation message: please use Partitions(n) instead ... return number_of_partitions(n) in sage.combinat.all: from partition import number_of_partitions_deprecated as number_of_partitions Also, we need to update a few doctests in the sage sources that use this function and will now need to import it (see sage.misc.superseded, sage.misc.cachefunc). See also the related failures in sage.combinat.posets.hasse_diagram, sage/combinat/posets/poset_examples. Cheers, Nicolas -- Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: 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/-/xQ93oikIZpgJ. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
ps. The list of functions disappearing from the global name space is: -RestrictedPartitions, PartitionsGreatestLE, partitions_set,\ -number_of_partitions_set, number_of_partitions_list, \ -ordered_partitions, number_of_ordered_partitions, number_of_partitions,\ -partitions, cyclic_permutations_of_partition,\ -cyclic_permutations_of_partition_iterator, ferrers_diagram, \ -partitions_greatest, partitions_greatest_eq, partitions_restricted,\ -number_of_partitions_restricted, partitions_tuples, \ -number_of_partitions_tuples, partition_power, partition_sign, \ -partition_associated, partitions_list The functions associated with restricted partitions were all flagged for deprecation a long time ago so they are disappearing. Everything else is being deprecated in favour of the corresponding class method, via the new improved deprecation scheme, unless the function had been fagged for deprecation a long time ago in which case it is being deleted. 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/-/asyS7vb9Vh0J. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
Hi Andrew, On Thu, Aug 23, 2012 at 05:23:32AM -0700, Andrew Mathas wrote: I have to confess that I didn't really appreciate that I was deprecating these functions from the global name space but in any case I am in favour of doing so, so +1. I have to confess in return that I missed the fact that most of those functions were marked as deprecated in their docstrings. For all of those your clean up need no discussion: they should be completely deleted. If everyone agrees that this is a good idea then I will add deprecation warnings into sage.combinat.all. If the we vote to keep them then I'll reinstate the global names in the patch. In terms of the functions in doctests etc the best fix would be to change them so that use Partition(n).cardinality() etc. Again, I would hunt these down and fix them if people are in favour of deprecation. Could you make a list of those that were not marked as deprecated? I also vote for deprecating them, but other opinions are welcome. By the way, number_of_partitions is one of the few such functions that I didn't deprecate in partition.py. The reason for this is that this function is wrapped in a cached_function call and I didn't want to break this... I suspect that if simply put a cached_method decorator on Partition.cardinality() then this would have the same effect but as I wasn't sure I left it well enough alone. Is this true? There might be another reason for deprecating number_of_partitions in the interpreter but not in the code: the implementation is really really fast, and the cost of constructing Partitions(n) first might be comparatively non negligible for heavy use. Thanks for your clean up! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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] Re: number_of_partitions and friends
I am also fine with deprecating the methods in Andrew's patch. Best, Anne On 8/23/12 8:57 AM, Nicolas M. Thiery wrote: Hi Andrew, On Thu, Aug 23, 2012 at 05:23:32AM -0700, Andrew Mathas wrote: I have to confess that I didn't really appreciate that I was deprecating these functions from the global name space but in any case I am in favour of doing so, so +1. I have to confess in return that I missed the fact that most of those functions were marked as deprecated in their docstrings. For all of those your clean up need no discussion: they should be completely deleted. If everyone agrees that this is a good idea then I will add deprecation warnings into sage.combinat.all. If the we vote to keep them then I'll reinstate the global names in the patch. In terms of the functions in doctests etc the best fix would be to change them so that use Partition(n).cardinality() etc. Again, I would hunt these down and fix them if people are in favour of deprecation. Could you make a list of those that were not marked as deprecated? I also vote for deprecating them, but other opinions are welcome. By the way, number_of_partitions is one of the few such functions that I didn't deprecate in partition.py. The reason for this is that this function is wrapped in a cached_function call and I didn't want to break this... I suspect that if simply put a cached_method decorator on Partition.cardinality() then this would have the same effect but as I wasn't sure I left it well enough alone. Is this true? There might be another reason for deprecating number_of_partitions in the interpreter but not in the code: the implementation is really really fast, and the cost of constructing Partitions(n) first might be comparatively non negligible for heavy use. Thanks for your clean up! Cheers, Nicolas -- 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.
[sage-combinat-devel] Re: number_of_partitions and friends
Hi Nicolas, Could you make a list of those that were not marked as deprecated? I also vote for deprecating them, but other opinions are welcome. Here, I think, is the complete list together with their recommended replacements: deprecation(13072,'partitions_set is deprecated. Use SetPartitions instead.') deprecation(13072,'number_of_partitions_set is deprecated. Use SetPartitions instead.') deprecation(13072,'ordered_partitions is deprecated. Use OrderedPartitions instead.') deprecation(13072,'number_of_ordered_partitions is deprecated. Use OrderedPartitions().cardinality instead.') deprecation(13072,'partitions_greatest is deprecated. Use PartitionsGreatestLE instead.') deprecation(13072,'partitions_greatest_eq is deprecated. Use PartitionsGreatestEQ instead.') deprecation(13072,'partition_tuples is deprecated. Use PartitionTuples instead.') deprecation(13072,'number_of_partition_tuples is deprecated. Use PartitionTuples instead.') deprecation(13072,'partition_power is deprecated. Use Partition(mu).power() instead.') Even though these functions were not marked for deprecation, some one had written the corresponding classes to replace them already. Looking again at the code, the function cyclic_permutations_of_partition should probably also become a method of Partitions() but I didn't do this (yet?). There might be another reason for deprecating number_of_partitions in the interpreter but not in the code: the implementation is really really fast, and the cost of constructing Partitions(n) first might be comparatively non negligible for heavy use. Actually, this argument is not so compelling because the default way of computing the number of partitions is to call the cython function sage.combinat.partitions.number_of_partitions If speed is really an issue then people should be calling this directly. In actual fact, the current implementation of partition.number_of_partitions creates extra overhead with some argument parsing. Ultimately, the function either calls the cython code or it calls gap's NrPartitions(), if the number of parts are specified, or there is another option for using pari. I think that it would be better to deprecate partitions.number_of_partitions in favour of the cython code. Best, Andrew On Friday, 24 August 2012 01:57:26 UTC+10, Nicolas M. Thiery wrote: Hi Andrew, On Thu, Aug 23, 2012 at 05:23:32AM -0700, Andrew Mathas wrote: I have to confess that I didn't really appreciate that I was deprecating these functions from the global name space but in any case I am in favour of doing so, so +1. I have to confess in return that I missed the fact that most of those functions were marked as deprecated in their docstrings. For all of those your clean up need no discussion: they should be completely deleted. If everyone agrees that this is a good idea then I will add deprecation warnings into sage.combinat.all. If the we vote to keep them then I'll reinstate the global names in the patch. In terms of the functions in doctests etc the best fix would be to change them so that use Partition(n).cardinality() etc. Again, I would hunt these down and fix them if people are in favour of deprecation. By the way, number_of_partitions is one of the few such functions that I didn't deprecate in partition.py. The reason for this is that this function is wrapped in a cached_function call and I didn't want to break this... I suspect that if simply put a cached_method decorator on Partition.cardinality() then this would have the same effect but as I wasn't sure I left it well enough alone. Is this true? There might be another reason for deprecating number_of_partitions in the interpreter but not in the code: the implementation is really really fast, and the cost of constructing Partitions(n) first might be comparatively non negligible for heavy use. Thanks for your clean up! Cheers, Nicolas -- Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: 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/-/hKvx4fyLqdYJ. 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.
[sage-combinat-devel] Re: number_of_partitions and friends
I remembered that I did in fact discuss doing these deprecations on
sage-combinat when I said that I wanted to implement a functional partition
tuple class last year; see
https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/NFNRYjqoouM
Specifically, I proposed to:
3. Depreciate the following functions/classes in partition.py:
deprecation('partitions_set()
is deprecated. Use the
SetPartitions(S,k) instead')
deprecation('number_of_partitions_set() is deprecated. Use the
SetPartitions(S,k).cardinality() instead')
deprecation('number_of_partitions() is deprecated. Use the
Partitions(n).cardinality() or Compositions(n,k).cardinality()
instead')
deprecation('partitions() is deprecated. Use the iterator from
Partitions() instead')
deprecation('ordered_partitions() is deprecated. Use the
Compositions() instead')
deprecation('number_of_ordered_partitions() is deprecated. Use
the Compositions().cardinality() instead')
deprecation('partitions_greatest() is deprecated. Use
PartitionsGreatestLE(n,k).list() instead')
deprecation('partitions_greatest_eq() is deprecated. Use
PartitionsGreatestEQ(n,k).list() instead')
deprecation('partitions_tuples() is deprecated. Use
Multipartitions(n,k).list() instead')
deprecation('number_of__partition_tulpes() is deprecated. Use
Multipartitions(n,k).cardinality() instead')
deprecation('power_partition() is deprecated. Use
Partition(pi).power(k) instead')
4. Remove all of the code in partition.py that was depreciated in
2009.
At the time no one disagreed with the proposal although, as now, people
were not exactly clamouring for it to happen either:)
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/-/l246VGXxA60J.
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.
