Weirdness

Words (there is more to look at here)

• [done in sage-words] sage.combinat.word is not imported by default -- with the sage-words merge this is no longer an issue
• [done in sage-words] 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)

• 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

• Should we use "fatter" or "coarser" for the converse of "finer"?
• Composition([1,3,2]).parent() should return Compositions()

The following are being worked on http://[email protected]/sage_trac/ticket/5600:

• Composition(l) should accept any iterable l, and in particular a tuple:

  • sage: Composition((1,3,1)) = Composition([1,3,1])

• Missing concatenation

Dyck Words (trac #3269 has some fixes - merged in Sage 3.0.2.rc0)

• 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

• Partitions(n).random_element() is completely useless if n is even moderately large (~ 100)

  • Yes, random generation is done naively now. It's not trivial to do it correctly but would make a nice little project. See http://www2.toki.or.id/book/AlgDesignManual/BOOK/BOOK4/NODE153.HTM

• The partition* stuff is all redundant
• q-t analogs do not behave consistently w.r.t. accepting q and t as parameters or creating q,t inside the function

• 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
• p.boxes() returns coordinates as tuples; other functions (corners(), outside_corners(), etc.) use lists.
• p.arm_lengths() and p.leg_lengths() should be called p.arm_length_tableau(), ...
  • AM: I think that hook_lengths is right: these are properties of the partition and not any particular tableaux!
• p.size() sums the entries instead of getting p.parent().n
  • This is probably the least error prone way to do things since we haven't really decided on how to handle parents for combinatorial objects. Note that if you just construct the partition with Partition([3,2,1]), it has to sum up the entries anyway to get the current parent.
• p.associated() is an alias for p.conjugate(). Is it necessary?
  • Probably not. It was part of the "old code" in Sage.
• p.atom() is not defined
• p.boxes() would be better called p.cells()

  • I think of them as "boxes"

• 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?
  • It's from MuPAD-Combinat.
• p.ferrers_diagram() is basically redundant with p.pp()
• p.hook_lengths() should be called p.hook_length_tableau()
  • AM: I think that hook_lengths is right: these are properties of the partition and not any particular tableaux!
• 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 # This is really in SkewPartitions

• 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 to inside_corners()?
• p.pp() should be called p.pretty_print() or just p.print()
• p.r_core() and p.r_quotient() should be called core and quotient, and return Partitions, not lists
  • AM: will depreciate soon...
• p.reading_tableau() needs a definition
• p.remove_box() should be called p.remove_cell()
• p.to_exp() needs a better name
• p.upper_hook_lengths() should be called p.upper_hook_length_tableau() (also lower_hook_lengths)
• p.upper_hook_length(i,j,x) takes coordinates first, so can't be called with (*[i,j],x) (also lower_hook_length)
• p.frobenius_notation() should exist and 'from_frobenius' should also be an option in the constructor
• Bugs / trivial limitations:

  •    sage: P = Partitions(NonNegativeIntegers(), max_part = 3)
       sage: P.first() # triggers an error
       sage: P = Partitions(NonNegativeIntegers()) # triggers an error

Partitions Weirdness fixed in trac #3286 - merged in Sage 3.0.3.alpha0

• p.arm(i,j) and p.leg(i,j) should also be callable as p.arm([i,j]), p.leg([i,j]) (fixed in doc)
• p.arm_legs_coeff() is not defined (done)
• An reference, definition, or at least an example should be given for the q,t-analog of p.centralizer_size() (done)
• There should exist p.content(i,j) or p.content([i,j]) := j -i (done)
• p.generalized_pochhammer_symbol? needs a definition (done) and, better, a reference
• p.hook() should accept p.hook(i,j) or p.hook([i,j]) (done with doc)
• a function p.add_cell(i,j) is *really* needed (done)
• p.r_core() and p.r_quotient() need defintions and/or references. (done)
• p.remove_box(i,j) should understand p.remove_box([i,j]) (done in doc)
• p.upper_hook() needs a definition or reference (done)
• a function p.content(i,j) would be very useful (done)

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.to_major_code: cleanup the doc (spurious "math", formulas not in math mode)
• 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.major_code documentation should be checked (a variable is called "math" !)
• 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()
• Current implementation is quadratic in the length of the permutation
• Perhaps taking powers of permutations should work

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
• All the katabolism stuff needs better doc
• t.katabolism_sequence() gives an infinite loop if t is the empty tableau
• In Tableaux, there should be a reference to Standardtableaux and Semistandardtableaux

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