Differences between revisions 1 and 2
 ⇤ ← Revision 1 as of 2009-02-12 17:40:45 → Size: 1313 Editor: FlorentHivert Comment: ← Revision 2 as of 2009-02-12 18:14:57 → ⇥ Size: 2482 Editor: FlorentHivert Comment: Deletions are marked like this. Additions are marked like this. Line 4: Line 4: I'd like to discuss them here. The following are mostly notes from discussion with Nicolas. Once fixed this material should ends in the doc of CombinatorialClass. I'd like to discuss them here. The following are mostly notes from discussion with Nicolas. Once fixed this material should ends in the doc of CombinatorialClass. Please add comment at any places. Line 8: Line 8: The name of the ObjOrientedClasses should be uniform : let's take the example of permutations The name of the ObjOrientedClasses should be uniform : let's take the example of permutations Line 13: Line 13: The following function are standard and should be documented/publicized for all CombClass: The following function are standard and should be documented/publicized for all CombClass: Line 16: Line 16: The following function should be written but are not supposed to be called directly by the user: The following function should be written but are not supposed to be called directly by the user: Line 24: Line 24: The goal here is to be able to inherits smoothly from a combinatorial class to add extra mathematical structure (eg Poset, Group, Monoid). * By default each element created by a combinatorial class should have a parent (Permutations for example). * Any element should be constructed by an overloadable function and never by calling directly a class name. {{{_element_constructor}}} seems to be sage default. A solution is to set two (lazy)_attribute in the combinatorial class named {{{element_class}}} and {{{element_parent}}} Line 26: Line 32: == Bijection == == Bijections ==When two combinatorial classes As and Bs with object a and b from OOclass A and B are in bijection, there are several possibilities * a.to_B() and b.to_A() : this is practical for the user, from the combinatorial point of view. however there is no control on the class nor the parent of the results.  * As.from_B(b) and Bs.from_A(s) is more consistent. The combinatorial class knows its bijections.  * Hom(As, Bs).nameOftheBijection(a) ? It is maybe not a very strong rule. Possible exception A is very standard and B is very exotic. Then maybe one can only write b.to_A() and B.from_A

# Combinatorial Classes

There are a lot of design issues with concern combinatorial classes. I'd like to discuss them here. The following are mostly notes from discussion with Nicolas. Once fixed this material should ends in the doc of CombinatorialClass. Please add comment at any places.

## Interface and basic usage

The name of the ObjOrientedClasses should be uniform : let's take the example of permutations

• the combinatorial class of all permutations should be named Permutations (which is now permutations_all) the __init__ should take in charge to call sub-classes if needed.

• sub-comb-classes are called Permutations_constraints

• for the objects one removes the s as in Permutation

The following function are standard and should be documented/publicized for all CombClass:

• list

• count is the name fixed ? coherent with the rests of sage ?

The following function should be written but are not supposed to be called directly by the user:

• __contains__ what should the answer of [2,1,3] in permutations([2,1,3]) ?

• __iter__ this allows for the class itself to be iterated through. Therefore there is no need for iterator. The former should be deprecated and removed.

## Objects/Elements/Parents

The goal here is to be able to inherits smoothly from a combinatorial class to add extra mathematical structure (eg Poset, Group, Monoid).

• By default each element created by a combinatorial class should have a parent (Permutations for example).
• Any element should be constructed by an overloadable function and never by calling directly a class name. _element_constructor seems to be sage default.

A solution is to set two (lazy)_attribute in the combinatorial class named element_class and element_parent

## Bijections

When two combinatorial classes As and Bs with object a and b from OOclass A and B are in bijection, there are several possibilities

• a.to_B() and b.to_A() : this is practical for the user, from the combinatorial point of view. however there is no control on the class nor the parent of the results.
• As.from_B(b) and Bs.from_A(s) is more consistent. The combinatorial class knows its bijections.
• Hom(As, Bs).nameOftheBijection(a) ?

It is maybe not a very strong rule. Possible exception A is very standard and B is very exotic. Then maybe one can only write b.to_A() and B.from_A

CombinatorialClass (last edited 2010-02-04 23:36:59 by FlorentHivert)