Size: 2338
Comment:
|
Size: 4007
Comment:
|
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 7: |
== Combinatorial* (not considered very carefully) == | |
Line 8: | Line 10: |
* It would be nice for CombinatorialObject to have a method 'indices' which returns a list of the index of *every* occurrence of x | * 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 == |
Line 10: | Line 15: |
* Composition will all entries with '0' parts (but not, for example, negative parts). It's not clear that all methods make sense when '0' parts are allowed. | |
Line 15: | Line 21: |
== Dyck Words == | |
Line 22: | Line 29: |
== Integer Vectors == | |
Line 24: | Line 32: |
== Lyndon Words == | |
Line 25: | Line 34: |
* LyndonWords are not defined in the docstring | * LyndonWords? does not define Lyndon words == MultichooseNK == |
Line 28: | Line 38: |
* Necklaces are not defined in the docstring * PartitionsGreatestEQ, PartitionsGreatestLE, PartitionsInBox are redundant with Partitions * For the following comments, let p be a partition: |
== Necklaces == * Necklaces? does not define necklaces == Partitions == * 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 * (For the following comments, let p be a partition) |
Line 32: | Line 47: |
* p.arm_legs_coeff() is not explained | * p.arm_legs_coeff() is not defined |
Line 36: | Line 51: |
* An example should be given for the q,t-analog of p.centralizer_size() |
* An reference, definition, or at least an example should be given for the q,t-analog of p.centralizer_size() * 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_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 and option for the 'e' version |
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 all 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 class SignedComposition
Dyck Words
DyckWords? does not define Dyck words
DyckWord.b_statistic() is not explained
DyckWord.height() is not explained
DyckWord.peaks() is not explained
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 class IntegerVector (or Word, etc.)
WeightedIntegerVectors has no corresponding class WeightedIntegerVector (or IntegerVector, or Word, etc.)
Lyndon Words
LyndonWords has no corresponding 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
Necklaces
- Necklaces? does not define necklaces
Partitions
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
- (For the following comments, let p be a partition)
- p.arm_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()
- 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_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 and option for the 'e' version