Changes between Version 10 and Version 12 of Ticket #13072


Ignore:
Timestamp:
08/29/12 04:57:15 (7 years ago)
Author:
andrew.mathas
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #13072 – Description

    v10 v12  
    99The 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).
    1010
    11 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
     11PartitionTuples 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
    1212
    1313{{{
    1414     for component in mu:
    1515          do X
     16}}}
    1617
    17 }}}
    18 is different for partitions and partition tuples (in the first case, you expect to loop over the pars of the partition and in the second over the component of the tuple). To get around this both classes now have a components() method so that you can uniformly write
     18is 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
    1919
    2020{{{
     
    2929PartitionTuples(level=l, n=n)
    3030}}}
     31
    3132where `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.)
    3233
    33 Finally, in addition to these new classes as discussed previously on sage-combinat I have removed a bunch functions which were depreciated years ago. I also added normal_nodes() and good_nodes methods to Partition_class and 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).
     34Finally, 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).
    3435
    35 For discussion about the functions being deprecated please see the following two discssions on sage-combinat:
     36For discussion about the functions being deprecated please see the following two discussions on sage-combinat:
    3637    * [https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/NFNRYjqoouM Implementation of partition tuples]
    3738    * [https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/utAsQzZQKLo number_of_partitions and friends]