Differences between revisions 28 and 29
Revision 28 as of 2008-05-21 00:40:35
Size: 9201
Editor: JasonBandlow
Comment:
Revision 29 as of 2008-05-21 01:07:43
Size: 9376
Editor: DanDrake
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

Line 90: Line 92:
  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
  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
Line 93: Line 95:
  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
  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
Line 99: Line 101:
 * p.isignature, p.iswitch, p.iflip deserve references to Assaf.   * p.isignature, p.iswitch, p.iflip deserve references to Assaf.
Line 118: Line 120:
 * 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
   3. tableau_by_shape? should emphasize that it simply fills the given shape with p in reading order--no col-strict condition is enforced
   4. permutation_group_element should emphasize that this can be used to act on polynomials
 * 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
Line 128: Line 130:
 * q_pochhammer or q-series = (a;q)_n := \prod_{k=0}^{n-1} (1 - aq^k) should be implemented  * q_pochhammer or q-series = (a;q)_n := \prod_{k=0}^{n-1} (1 - aq^k) should be implemented.
Line 135: Line 137:
== More to come...==
Line 136: Line 139:
== 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)

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

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

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?
    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
    3. tableau_by_shape? should emphasize that it simply fills the given shape with p in reading order--no col-strict condition is enforced
    4. 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

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