334
Comment:
|
9814
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
== Words (there is more to look at here) == |
|
Line 6: | Line 9: |
== Combinatorial* (not considered very carefully) == | |
Line 8: | Line 12: |
* It would be nice for CombinatorialObject to have a method 'indices' which returns a list of the index of *every* occurrence of x == Combinations == * Looks good! (Just recording here that it was looked at). == Compositions == * Compositions has no option for allowing '0' parts (which are often useful) (IntegerVectors does this. There should be a pointer.) * Composition will allow entries with '0' parts (but not, for example, negative parts). It's not clear that all methods make sense when '0' parts are allowed. * Composition.conjugate() is not explained * Composition.descents() is not explained * Composition.major_index() doc-string says it is the sum of the descents. This is not true for the given example. * Composition.refinement() is not explained * SignedCompositions has no corresponding element class SignedComposition == Dyck Words (Being worked on by JRB) == * DyckWords? does not define Dyck words (done) * DyckWord.b_statistic() is not explained (done) * DyckWord.height() is not explained (done) * DyckWord.peaks() is not explained (done, BUT: sage's definition is *not* Haglund's definition. what is this function for? * DyckWord.to_noncrossing_partition() could use a better reference * DyckWord.to_tableau is not explained * DyckWord.to_* for * in {ordered_tree, triangulation} is not implemented. Warning: Implementing bijections between Catalan objects can be a never-ending task. == Integer Vectors == * IntegerVectors has no corresponding element class IntegerVector (or Word, etc.) * WeightedIntegerVectors has no corresponding element class WeightedIntegerVector (or IntegerVector, or Word, etc.) == Lyndon Words == * LyndonWords has no corresponding element class LyndonWord (or Word, etc.) * LyndonWords? does not define Lyndon words == MultichooseNK == * MultichooseNK has no useful documentation * The name MultichooseNK does not compare well with Combinations, though they do very similar things * Actually calling MultichooseNK(3,2) returns a scary error message (probably due to a problem in CombinatorialClass) == Tuples == * This has very similar functionality to Combinations and MultichooseNK. These names should be made more consistent somehow. == Necklaces == * Necklaces? does not define necklaces == Partitions == * Perhaps a PartitionsOptions Class could be added where one could specify: French vs. English, maybe Dominance vs. Lex(?), others? The PermutationsOptions class is a good idea! * PartitionsGreatestEQ, PartitionsGreatestLE, PartitionsInBox are redundant with options passed to Partitions * The doc for Partition should point out that < compares lexicographically * The doc for Partition says 'Sage uses the English convention...' this should be expanded and mention 0-indexing; in fact it should also mention that partitions can be interpreted as diagrams * The partition* stuff is all redundant * p.arm(i,j) and p.leg(i,j) should also be callable as p.arm([i,j]), p.leg([i,j]) * (For the following comments, let p be a partition) * p.arm_lengths() and p.leg_lengths() should be called p.arm_length_tableau(), ... * p.arm_legs_coeff() is not defined * p.associated() is an alias for p.conjugate(). Is it necessary? * p.atom() is not defined * p.boxes() would be better called p.cells() * An reference, definition, or at least an example should be given for the q,t-analog of p.centralizer_size() * There should exist p.content(i,j) or p.content([i,j]) := j -i * p.character_polynomial() deserves a reference * p.dominate() should be called p.dominated_partitions() (or something more clear) * p.down(), p.down_list(), p.up(), p.up_list() could have better names? (restrict/induce? is there a convention for a generator vs a list? is this too redundant?) * is p.evaluation() a standard name? * p.ferrers_diagram() is basically redundant with p.pp() * p.generalized_pochhammer_symbol? needs a definition and, better, a reference * p.hook() should accept p.hook(i,j) or p.hook([i,j]) * p.hook_lengths() should be called p.hook_length_tableau() * p.hook_polynomial() needs a definition and/or reference * p.hook_product() needs a definition and/or reference, and the parameter should default to 1 * the following example blows up: {{{sage: m = p.jacobi_trudi(); m.row(0)}}} * p.jacobi_trudi() should also include an option for the 'e' version * p.k_atom() needs a definition or reference * p.k_conjugate() could use a reference * p.k_split() needs a definition or reference * given p.outside_corners() should p.corners() be renamed? * a function p.add_cell(i,j) (also taking p.add_cell([i,j])) is *really* needed * p.pp() should be called p.pretty_print() or just p.print() * p.r_core() and p.r_quotient() need defintions and/or references. Also should be called core and quotient * p.reading_tableau() needs a definition * p.remove_box() should be called p.remove_cell() * p.remove_box(i,j) should understand p.remove_box([i,j]) * p.to_exp() needs a better name * p.upper_hook() needs a definition or reference * p.upper_hook_lengths() should be called p.upper_hook_length_tableau() == SkewPartitions == * Commonalities with Partitions should be factored out! (hook lengths, for one example) == Permutations == * Permutations doc should define Bruhat order and recoils * Permutation doc should reference PermutationOptions * The Permutation constructor does not check enough: Permutation([1,1,1]) and Permutation([-3,7]) don't break, for example * For the following, let p be a Permutation * p.action? could mention that to_permutation_group() allows for an action on polynomials * p.bruhat_* : 1. greater/smaller return comb. classes, inversions,pred,succ return lists, *_iterator return iterators. Can this be made more consistent? 1. Bruhat order should be defined or referenced in all of these * p.permutahedron_* : 1. These all return lists (except for lequal() which is ok). Compare with bruhat above 1. Left and right permutahedron order should be defined or referenced in all of these * p.charge() and p.cocharge() need to be implemented, p.ascents() would also possibly be useful * Typo in p.cycle_type? (non-increasing -> non-decreasing) * p.descents_composition? needs a definition of descent and an explanation of how to get the comp. * p.has_pattern() is redundant with p.avoids? * p.isignature, p.iswitch, p.iflip deserve references to Assaf. * p.iswitch? should mention that these are the dual knuth relations * the (non-dual) knuth relations should be implemented, as well as the boolean p.knuth_equivalent(q) * p.left_tableau? says it returns the right tableaux (but it's lying) * the only example for p.left_tableau() and p.right_tableau() is an involution; thus they are not distinguished * p.left_tableau? and p.right_tableau? should provide a specific reference to the algorithm * p.longest_increasing_subsequence() should be called p.longest_increasing_subsequences() (plural) * p.major_index? typo: "add one the number of" -> "add one to each of" * p.number_of_descents? should define descent and explain the final_descents option * p.number_of_idescents? should include the word 'inverse' and explain final_descents * p.number_of_recoils? should define recoil * p.number_of_saliances? should define saliances * p.recoils_composition? needs a definition of recoil and an explanation of how to get the comp. * p.reduced_word() implies there is only one. Is the point that it is faster than p.reduced_word_lexmin() ? * p.reduced_word* should all define or reference reduced words in the doc * p.remove_extra_fixed_points() should be called p.remove_trailing_fixed_points(). When applied to [1] it should return [] * p.robinson_schensted? should provide a specific reference to the algorithm * p.runs? should define runs... the definition is quite short * p.signature? should define signature * p.to_* 1. is the 'to' needed in the name? ex: p.to_cycles() could be called p.cycles() to be compatible with p.cycle_string() 1. lehmer_code? and lehmer_cocode? should be defined 1. tableau_by_shape? should emphasize that it simply fills the given shape with p in reading order--no col-strict condition is enforced 1. permutation_group_element should emphasize that this can be used to act on polynomials * Perhaps p.excedences() would be useful, as well as p.weak_excedences() == PermutationGroup* == * Not generally considered (i'm exhausted on permutations) but is it possible for PermutationGroupElement to be merged with Permutation? == q_analogues.py == * These are extremely useful and should be generally available * q_pochhammer or q-series = (a;q)_n := \prod_{k=0}^{n-1} (1 - aq^k) should be implemented. == SetPartitions* == * Are all the names SetPartitions*k necessary in the global namespace? == Tableau == * The following are for t a Tableau * t.major_index is not what most people call the major index of a tableaux. This should be called dmaj. * There should be a general method for adding a row or a cell, or changing a cell == More to come... == This is a great page. There is lots of weirdness in the combinatorics stuff, and we should really clean it up. I can start working on the simpler stuff here next week. --DanDrake |
Weirdness
Words (there is more to look at here)
- sage.combinat.word is not imported by default
- word.symmetric_group_action_on_values does not naturally belong in word
- word.standard should be called word.standardization
- word.charge returns the cocharge
Combinatorial* (not considered very carefully)
CombinatorialAlgebra has no useful documentation
CombinatorialClass has no documentation
It would be nice for CombinatorialObject to have a method 'indices' which returns a list of the index of *every* occurrence of x
Combinations
- Looks good! (Just recording here that it was looked at).
Compositions
Compositions has no option for allowing '0' parts (which are often useful) (IntegerVectors does this. There should be a pointer.)
- Composition will allow entries with '0' parts (but not, for example, negative parts). It's not clear that all methods make sense when '0' parts are allowed.
- Composition.conjugate() is not explained
- Composition.descents() is not explained
- Composition.major_index() doc-string says it is the sum of the descents. This is not true for the given example.
- Composition.refinement() is not explained
SignedCompositions has no corresponding element class SignedComposition
Dyck Words (Being worked on by JRB)
DyckWords? does not define Dyck words (done)
DyckWord.b_statistic() is not explained (done)
DyckWord.height() is not explained (done)
DyckWord.peaks() is not explained (done, BUT: sage's definition is *not* Haglund's definition. what is this function for?
DyckWord.to_noncrossing_partition() could use a better reference
DyckWord.to_tableau is not explained
DyckWord.to_* for * in {ordered_tree, triangulation} is not implemented. Warning: Implementing bijections between Catalan objects can be a never-ending task.
Integer Vectors
IntegerVectors has no corresponding element class IntegerVector (or Word, etc.)
WeightedIntegerVectors has no corresponding element class WeightedIntegerVector (or IntegerVector, or Word, etc.)
Lyndon Words
LyndonWords has no corresponding element class LyndonWord (or Word, etc.)
LyndonWords? does not define Lyndon words
MultichooseNK
- MultichooseNK has no useful documentation
- The name MultichooseNK does not compare well with Combinations, though they do very similar things
Actually calling MultichooseNK(3,2) returns a scary error message (probably due to a problem in CombinatorialClass)
Tuples
- This has very similar functionality to Combinations and MultichooseNK. These names should be made more consistent somehow.
Necklaces
- Necklaces? does not define necklaces
Partitions
Perhaps a PartitionsOptions Class could be added where one could specify: French vs. English, maybe Dominance vs. Lex(?), others? The PermutationsOptions class is a good idea!
PartitionsGreatestEQ, PartitionsGreatestLE, PartitionsInBox are redundant with options passed to Partitions
The doc for Partition should point out that < compares lexicographically
- The doc for Partition says 'Sage uses the English convention...' this should be expanded and mention 0-indexing; in fact it should also mention that partitions can be interpreted as diagrams
- The partition* stuff is all redundant
- p.arm(i,j) and p.leg(i,j) should also be callable as p.arm([i,j]), p.leg([i,j])
- (For the following comments, let p be a partition)
- p.arm_lengths() and p.leg_lengths() should be called p.arm_length_tableau(), ...
- p.arm_legs_coeff() is not defined
- p.associated() is an alias for p.conjugate(). Is it necessary?
- p.atom() is not defined
- p.boxes() would be better called p.cells()
- An reference, definition, or at least an example should be given for the q,t-analog of p.centralizer_size()
- There should exist p.content(i,j) or p.content([i,j]) := j -i
- p.character_polynomial() deserves a reference
- p.dominate() should be called p.dominated_partitions() (or something more clear)
- p.down(), p.down_list(), p.up(), p.up_list() could have better names? (restrict/induce? is there a convention for a generator vs a list? is this too redundant?)
- is p.evaluation() a standard name?
- p.ferrers_diagram() is basically redundant with p.pp()
- p.generalized_pochhammer_symbol? needs a definition and, better, a reference
- p.hook() should accept p.hook(i,j) or p.hook([i,j])
- p.hook_lengths() should be called p.hook_length_tableau()
- p.hook_polynomial() needs a definition and/or reference
- p.hook_product() needs a definition and/or reference, and the parameter should default to 1
- the following example blows up:
sage: m = p.jacobi_trudi(); m.row(0)
- p.jacobi_trudi() should also include an option for the 'e' version
- p.k_atom() needs a definition or reference
- p.k_conjugate() could use a reference
- p.k_split() needs a definition or reference
- given p.outside_corners() should p.corners() be renamed?
- a function p.add_cell(i,j) (also taking p.add_cell([i,j])) is *really* needed
- p.pp() should be called p.pretty_print() or just p.print()
- p.r_core() and p.r_quotient() need defintions and/or references. Also should be called core and quotient
- p.reading_tableau() needs a definition
- p.remove_box() should be called p.remove_cell()
- p.remove_box(i,j) should understand p.remove_box([i,j])
- p.to_exp() needs a better name
- p.upper_hook() needs a definition or reference
- p.upper_hook_lengths() should be called p.upper_hook_length_tableau()
SkewPartitions
- Commonalities with Partitions should be factored out! (hook lengths, for one example)
Permutations
- Permutations doc should define Bruhat order and recoils
Permutation doc should reference PermutationOptions
- The Permutation constructor does not check enough: Permutation([1,1,1]) and Permutation([-3,7]) don't break, for example
- For the following, let p be a Permutation
- p.action? could mention that to_permutation_group() allows for an action on polynomials
- p.bruhat_* :
- greater/smaller return comb. classes, inversions,pred,succ return lists, *_iterator return iterators. Can this be made more consistent?
- Bruhat order should be defined or referenced in all of these
- p.permutahedron_* :
- These all return lists (except for lequal() which is ok). Compare with bruhat above
- Left and right permutahedron order should be defined or referenced in all of these
- p.charge() and p.cocharge() need to be implemented, p.ascents() would also possibly be useful
Typo in p.cycle_type? (non-increasing -> non-decreasing)
- p.descents_composition? needs a definition of descent and an explanation of how to get the comp.
- p.has_pattern() is redundant with p.avoids?
- p.isignature, p.iswitch, p.iflip deserve references to Assaf.
- p.iswitch? should mention that these are the dual knuth relations
- the (non-dual) knuth relations should be implemented, as well as the boolean p.knuth_equivalent(q)
- p.left_tableau? says it returns the right tableaux (but it's lying)
- the only example for p.left_tableau() and p.right_tableau() is an involution; thus they are not distinguished
- p.left_tableau? and p.right_tableau? should provide a specific reference to the algorithm
- p.longest_increasing_subsequence() should be called p.longest_increasing_subsequences() (plural)
p.major_index? typo: "add one the number of" -> "add one to each of"
- p.number_of_descents? should define descent and explain the final_descents option
- p.number_of_idescents? should include the word 'inverse' and explain final_descents
- p.number_of_recoils? should define recoil
- p.number_of_saliances? should define saliances
- p.recoils_composition? needs a definition of recoil and an explanation of how to get the comp.
- p.reduced_word() implies there is only one. Is the point that it is faster than p.reduced_word_lexmin() ?
- p.reduced_word* should all define or reference reduced words in the doc
- p.remove_extra_fixed_points() should be called p.remove_trailing_fixed_points(). When applied to [1] it should return []
- p.robinson_schensted? should provide a specific reference to the algorithm
- p.runs? should define runs... the definition is quite short
- p.signature? should define signature
- p.to_*
- is the 'to' needed in the name? ex: p.to_cycles() could be called p.cycles() to be compatible with p.cycle_string()
- lehmer_code? and lehmer_cocode? should be defined
- tableau_by_shape? should emphasize that it simply fills the given shape with p in reading order--no col-strict condition is enforced
- permutation_group_element should emphasize that this can be used to act on polynomials
- Perhaps p.excedences() would be useful, as well as p.weak_excedences()
PermutationGroup*
Not generally considered (i'm exhausted on permutations) but is it possible for PermutationGroupElement to be merged with Permutation?
q_analogues.py
- These are extremely useful and should be generally available
q_pochhammer or q-series = (a;q)_n := \prod_{k=0}{n-1} (1 - aqk) should be implemented.
SetPartitions*
Are all the names SetPartitions*k necessary in the global namespace?
Tableau
- The following are for t a Tableau
- t.major_index is not what most people call the major index of a tableaux. This should be called dmaj.
- There should be a general method for adding a row or a cell, or changing a cell
More to come...
This is a great page. There is lots of weirdness in the combinatorics stuff, and we should really clean it up. I can start working on the simpler stuff here next week. --DanDrake