#13072: Implementation of PartitionTuple + some minor fixes to partition.py
----------------------------------------+-----------------------------------
Reporter: andrew.mathas | Owner: Andrew Mathas
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.3
Component: combinatorics | Resolution:
Keywords: tuples of partitions | Work issues:
Report Upstream: N/A | Reviewers: Travis Scrimshaw
Authors: Andrew Mathas | Merged in:
Dependencies: #9265 | Stopgaps:
----------------------------------------+-----------------------------------
Description changed by andrew.mathas:
Old description:
> 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
> }}}
> mprovements welcome!
>
> 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
>
> {{{
> PartitionTuples(level=l, n=n)
> }}}
>
> where `level` and `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 `n` with `size` would also be sensible but I didn't go there.)
>
> 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:
> * [https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-
> devel/NFNRYjqoouM Implementation of partition tuples]
> * [https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-
> devel/utAsQzZQKLo number_of_partitions and friends]
>
> Below is a summary of the above listed 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. ''In fact, this leads to a dramatic speed-
> up. See the timings below''.
>
> 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.
>
> '''Apply:''' [attachment:trac_13072-tuples-of-tableaux-am.patch]
New description:
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
}}}
mprovements welcome!
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
{{{
PartitionTuples(level=l, n=n)
}}}
where `level` and `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 `n` with `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:
* [https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-
devel/NFNRYjqoouM Implementation of partition tuples]
* [https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-
devel/utAsQzZQKLo number_of_partitions and friends]
Below is a summary of the above listed 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. ''In fact, this leads to a dramatic speed-
up. See the timings below''.
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.
'''Apply:''' [attachment:trac_13072-tuples-of-tableaux-am.patch]
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13072#comment:15>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
