Differences between revisions 77 and 83 (spanning 6 versions)
Revision 77 as of 2012-01-20 09:38:29
Size: 14485
Editor: nborie
Comment:
Revision 83 as of 2018-11-03 12:36:52
Size: 14924
Editor: chapoton
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * no global rule for containance method (should "sage: [1,3,2] in Permutations(3)" answer True or False ?). Currently, it is specified in NO class what should be await from this function!
 * general framework to add constraints to a class (as "sage: Partitions(3).add_constraint(length=2)"). The only actual possibility is to filter the output as in ("sage: Partitions(3).filter(lambda x: len(x) == 2)") which is bad in this case because there is a dedicated class for partitions with constrained length! This question arise from both user point of vue (nice methods to do things quickly) and programer (what kind of relations between a class and a constrained class). In the new GradedEnumeratedSets framework (`trac #10193 <http://trac.sagemath.org/sage_trac/ticket/10193>`_), it is suggested to use .subset()
 * a related question is about when constraints defined the empty set. Should the return value of the constructor be the emptyset ?
 * no global rule for containance test (should "sage: [1,3,2] in Permutations(3)" answer True or False ?). Currently, it is specified in NO class what should be await from this function!
 * specifications of error raised by rank/unrank (see also [[http://groups.google.com/group/sage-combinat-devel/browse_thread/thread/8c7e616013ad37c9/cd1ed8a70e9ce8fc|thread on sage-devel]])
 * what should be the equality of two finite enumerated sets ?
Line 69: Line 69:
== 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)
Line 74: Line 70:
 * This has very similar functionality to Combinations and MultichooseNK. These names should be made more consistent somehow.  * This has very similar functionality to Combinations. These names should be made more consistent somehow.
Line 80: Line 76:
 * 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!  * Perhaps a PartitionOptions Class could be added where one could specify: French vs. English, maybe Dominance vs. Lex(?), others? The PermutationOptions class is a good idea! [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]]
Line 86: Line 82:
 * The doc for Partition should point out that < compares lexicographically  * The doc for Partition should point out that < compares lexicographically [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]]
Line 88: Line 84:
   * TS: [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]] will move the English convention problem to PartitionOptions
Line 89: Line 86:
 * p.arm_lengths() and p.leg_lengths() should be called p.arm_length_tableau(), ...    * TS: Already fixed somewhere
 * p.*_lengths() should be called p.*_length_tableau(). For example p.arm_lengths() should be p.arm_length_tableau().
Line 91: Line 89:
 * 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.
   * TS: The result is a tableau where the entries are the *_length().
 * 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.
Line 95: Line 94:
   * TS: Already removed somewhere
Line 98: Line 98:
   * In [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]] there will be a note in the header about partitions using cells. However we could implement aliases...
Line 100: Line 101:
   * TS: [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]] and will deprecate the old name
Line 103: Line 105:
 * 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!
   * TS: [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]] gives better documentation for this function and why it is named as such.
Line 108: Line 108:
   * Second part in [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]]
Line 117: Line 118:
   * TS: I believe corners is a standard name, however I setup an alias in [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]].
 * p.ferrers_diagram() is basically redundant with p.pp()
   * TS: I think this should be separate since {{{p.ferrers_diagram()}}} returns a string representing the partition whereas {{{p.pp()}}} actually prints the diagram.
Line 118: Line 122:
   * TS: I believe this is to be consistent with other such things in sage (in particular tableaux), and as such, we should leave it p.pp().
Line 120: Line 125:
 * p.reading_tableau() needs a definition  * p.reading_tableau() needs a definition [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]]
Line 122: Line 127:
   * TS: Already done somewhere
Line 123: Line 129:
 * 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.upper_hook_length(i,j,x) takes coordinates first, so can't be called with (*[i,j],x) (also lower_hook_length) [[http://trac.sagemath.org/sage_trac/ticket/13605|#13605]]
   * TS: Would it be natural for alpha to default to 1? If so, then I think we should change this to have an optional argument to handle input of a cell.
Line 126: Line 132:
 * Bugs / trivial limitations:
   {{{
   sage: P = Partitions(NonNegativeIntegers(), max_part = 3)
   sage: P.first() # triggers an error
   sage: P = Partitions(NonNegativeIntegers()) # triggers an error
   }}}
   * Already done somewhere
Line 200: Line 200:
 * t.katabolism_sequence() gives an infinite loop if t is the empty tableau  * t.catabolism_sequence() gives an infinite loop if t is the empty tableau (solved)
Line 204: Line 204:
 * Method to compute J(P) is missing  * Method to compute J(P) is missing (done) P.order_ideals_lattice()

Weirdness

Conventions for EnumeratedSets (Partitions, Permutations, Subsets, Subwords, ...)

  • no global rule for containance test (should "sage: [1,3,2] in Permutations(3)" answer True or False ?). Currently, it is specified in NO class what should be await from this function!
  • specifications of error raised by rank/unrank (see also thread on sage-devel)

  • what should be the equality of two finite enumerated sets ?

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
  • Language as Parent / Word as Element. Merge FreeMonoid and Words #12224

  • Classes for languages #12225, #12227, ...

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.
    • This should not be allowed (in particular [0,1] in Compositions() should return False). IntegerVectors can handle this functionality.

  • 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://trac.sagemath.org/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
  • inner / outer returns error when set with Composition instance
    •        sage: c=Composition([3,5,7,2])
             sage: C=Compositions(17,outer=c)
             sage: C
             Compositions of the integer 17 satisfying constraints outer=[3, 5, 7, 2]
             sage: C.list()
             TypeError                Traceback (most recent call last)
             ...
             TypeError: 'Composition_class' object is not callable

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.)

  • Make that elements are hashable (and thus can index basis of nice free module)
  • Make more clear (checks and documentation) the consideration of trailing zeros
  • Allows the customisation with a post_process (and thus facade parent)
  • More documentation about possible extra arguments
  • Test coherence and compatibility of extra arguments (raise NotImplementedError to avoid returning error!!!!)

  • WeightedIntegerVectors has no corresponding element class WeightedIntegerVector (or IntegerVector, or Word, etc.)

Lyndon Words

Tuples

  • This has very similar functionality to Combinations. These names should be made more consistent somehow.

Necklaces

  • Necklaces? does not define necklaces

Partitions

  • Perhaps a PartitionOptions Class could be added where one could specify: French vs. English, maybe Dominance vs. Lex(?), others? The PermutationOptions class is a good idea! #13605

  • PartitionsGreatestEQ, PartitionsGreatestLE, PartitionsInBox are redundant with options passed to Partitions

  • Partitions(n).random_element() is completely useless if n is even moderately large (~ 100)
  • 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 #13605

  • 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.
    • TS: Already fixed somewhere
  • p.*_lengths() should be called p.*_length_tableau(). For example p.arm_lengths() should be p.arm_length_tableau().
    • AM: I think that hook_lengths is right: these are properties of the partition and not any particular tableaux!
    • TS: The result is a tableau where the entries are the *_length().
  • 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.
    • TS: Already removed somewhere
  • p.atom() is not defined
  • p.boxes() would be better called p.cells()
    • I think of them as "boxes" :-)

    • In #13605 there will be a note in the header about partitions using cells. However we could implement aliases...

  • p.character_polynomial() deserves a reference
  • p.dominate() should be called p.dominated_partitions() (or something more clear)
    • TS: #13605 and will deprecate the old name

  • 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.
    • TS: #13605 gives better documentation for this function and why it is named as such.

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

    • This is because the symmetric function algebra does not have an is_integral_domain attribute

  • p.jacobi_trudi() should also include an option for the 'e' version # This is really in SkewPartitions

  • p.jacobi_trudi() returns the transpose of the conventional Jacobi-Trudi matrix
  • 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()?
    • TS: I believe corners is a standard name, however I setup an alias in #13605.

  • p.ferrers_diagram() is basically redundant with p.pp()
    • TS: I think this should be separate since p.ferrers_diagram() returns a string representing the partition whereas p.pp() actually prints the diagram.

  • p.pp() should be called p.pretty_print() or just p.print()
    • TS: I believe this is to be consistent with other such things in sage (in particular tableaux), and as such, we should leave it p.pp().
  • 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 #13605

  • p.remove_box() should be called p.remove_cell()
    • TS: Already done somewhere
  • p.to_exp() needs a better name
  • p.upper_hook_length(i,j,x) takes coordinates first, so can't be called with (*[i,j],x) (also lower_hook_length) #13605

    • TS: Would it be natural for alpha to default to 1? If so, then I think we should change this to have an optional argument to handle input of a cell.
  • p.frobenius_notation() should exist and 'from_frobenius' should also be an option in the constructor
    • Already done somewhere

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 (trac #8918)
  • 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
  • More permutation statistics would be useful: E.g., p.excedences(), p.weak_excedences(), p.ascents(), p.valleys() and p.components()
  • 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?

SymmetricFunctions

  • The following are for f a symmetric function
  • f._is_positive(basis) should not be hidden

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.catabolism_sequence() gives an infinite loop if t is the empty tableau (solved)
  • In Tableaux, there should be a reference to Standardtableaux and Semistandardtableaux

Posets

  • Method to compute J(P) is missing (done) P.order_ideals_lattice()

Category Framework

  • Defining an_element of a Parent in a naive way (involving multiplication of a coefficient and a term) will lead to an infinite recursion. See an_element in sfa.py for a definition which works.

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)