Differences between revisions 23 and 24
Revision 23 as of 2008-05-20 19:51:29
Size: 5420
Editor: JasonBandlow
Comment:
Revision 24 as of 2008-05-20 21:10:58
Size: 7671
Editor: JasonBandlow
Comment:
Deletions are marked like this. Additions are marked like this.
Line 79: Line 79:
 * The keywords called 'recoils' in Permutations should perhaps be called 'ascents'  * Permutations doc should define Bruhat order and recoils
Line 85: Line 85:
 * p.permutahedron_* :
   1. These all return lists (except for lequal() which is ok). Compare with bruhat above
   2. 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()
   2. lehmer_code? and lehmer_cocode? should be defined
 

 

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)

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

  • 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

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
  • 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()
  • 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 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()

Permutations

  • Permutations doc should define Bruhat order and recoils
  • 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.bruhat_* :
    1. greater/smaller return comb. classes, inversions,pred,succ return lists, *_iterator return iterators. Can this be made more consistent?
    2. 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
    2. 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()
    2. lehmer_code? and lehmer_cocode? should be defined

combinat/Weirdness (last edited 2018-11-06 19:45:34 by chapoton)