Implementation of PartitionTuple + some minor fixes to partition.py
|Reported by:||andrew.mathas||Owned by:||Andrew Mathas|
|Component:||combinatorics||Keywords:||tuples of partitions|
|Authors:||Andrew Mathas||Reviewers:||Travis Scrimshaw|
|Report Upstream:||N/A||Work issues:|
Description (last modified by )
This patch implements the following classes:
- PartitionTuple - returns a tuple of partitions
- PartitionTuples - factory class for all tuples of partitions
- !PartitionTuples_level - class of all tuples of partition of a fixed level
- !PartitionTuples_size - class of all tuples of partition of a fixed size
- !PartitionTuples_level_size - class of all tuples of partition of a fixed level and size. The first three of these are infinite enumerated classes whereas the last is finite. They all have iterators.
The idea is to implement a fully function class for PartitionTuples as I currently need this together with a class for tuples of (standard) tableaux (coming soon).
PartitionTuples of level 1 are in natural bijection with Partitions so when given a 1-tuple of partitions, or a partition, PartitionTuples() returns the corresponding Partition. This works almost seamlessly, making it possible to almost ignore the distinction between Partitions() and PartitionTuples(). One exception is that the expected behaviour of
for component in mu: do X
is different for partitions and partition tuples (in the first case, you expect to loop over the parts of the partition and in the second over the components of the tuple). To get around this both classes now have a components() method so that you can uniformly write
for nu in mu.components(): do X
In terms of implementation, for my use of these objects the
level is more intrinsic than the size so I have set the syntax for the PartitionTuples? classes as
n are both optional named arguments BUT level is specified first. Previously,
n was given first and
level second. I think that it makes much more sense this way around, but if people feel really strongly about this I will change it back. Previously,
level was just called
k, which is a fairly random variable whereas
level makes sense in terms of categorification and higher level Fock spaces. (Replacing
size would also be sensible but I didn't go there.)
Deprecations of old functions: Finally, in addition to these new classes I have removed a bunch functions which were depreciated years ago and depreciated some more functions, as discussed on sage-combinat. I also reinstated the beta_numbers() methods which were removed in the last patch to partition.py (this patch said that beta_numbers and frobenius_coordinates are identical objects, but they are actually different).
For discussion about the functions being deprecated please see the following two discussions on sage-combinat:
Below is a summary of the above listed in order of what I think is decreasing controversy.
- 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.
- 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 use a cached version of number_of_partitions() inside partition.py always. As shown in the comments below, this leads to a dramatic speed-up.
This probably should be revisited when Fredrik Johansson's patch #13199, which uses FLINT to implement a faster version of number_of_partitions, is merged into sage.
- The two functions
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.
- The following functions were marked for deprecation several years ago so they have been removed from sage.combinat.partition.py:
- For the reasons given in #5478, RestrictedPartitions? was also slated for removal but it was decided not to deprecate this class until Partitions() is able to process the appropriate combinations of keyword arguments. See #12278 and the comment by John Palmieri below for more details. Nicolas has suggested that one way of addressing this may be to refactor the partitions code so that it uses Florent's enumerated sets factories #10194.
- The following functions now give deprecation warnings and they are marked for removal from the global name space:
In all cases, these function are deprecated in favour of (methods in) parent classes.
Change History (56)
comment:1 Changed 4 years ago by
- Description modified (diff)
- Status changed from new to needs_review
comment:3 Changed 4 years ago by
- Dependencies changed from NA to #9265
- Description modified (diff)
- Priority changed from minor to major
comment:25 Changed 4 years ago by
- Dependencies changed from #9265 to #9265, #11446
- Status changed from needs_review to positive_review
comment:41 in reply to: ↑ 39 ; follow-up: ↓ 42 Changed 4 years ago by
comment:54 Changed 4 years ago by
- Merged in set to sage-5.5.beta1
- Resolution set to fixed
- Status changed from positive_review to closed