> > In fact I plan to get Catalan numbers and q-Catalan numbers and (as > > soon as they are found somewhere out there ;-)) q,t-Catalan numbers > > available. They can be defined by using the degrees and codegrees, > > that's why I was looking for those... > > Please discuss this with Mike Zabrocki, since he was doing much stuff > like that (but maybe only in MuPAD, and maybe only in type A).
He was doing only type A and, so far, there is no combinatorial way to define q,t-Catalans in other types. So I will do only q-Catalans which are much easier. I will talk to Mike about it... > > - CoxeterGroup are in fact finite Coxeter groups, and the few non-Weyl > > groups are not yet in sage. > > Not quite: > > sage: CoxeterGroup(["A",3,1]) > Weyl Group of type ['A', 3, 1] (as a matrix group acting on the root > space) > sage: CoxeterGroup(["H",3]) > Permutation Group with generators > [(2,6)(3,18)(4,8)(5,9)(7,10)(11,12)(13,14)(17,21)(19,23)(20,24)(22,25)(26,2 > 7)(28,29), > (1,4)(2,17)(3,6)(5,7)(9,11)(10,12)(14,15)(16,19)(18,21)(20,22)(24,26)(25,27 > )(29,30), > (1,16)(2,5)(4,7)(6,9)(8,10)(11,13)(12,14)(17,20)(19,22)(21,24)(23,25)(26,28 > )(27,29)] You're right, there are the affine groups as well. I don't know why, but CoxeterGroup(['H',3]) didn't work for me, even though I applied the whole combinat queue. > But yes, not all Coxeter groups are implemented, and the second one > above uses GAP3, which is not in plain Sage yet. Maybe we can start getting some things done directly in sage... > The later is not a method but a nested class. Whether it should show > up during introspection is questionable. It could possibly be renamed > to _AmbientSpace. But then so should most other nested classes (like > the ParentMethods/... of categories. I see. > I am speaking from the technical side here. For simplicity, data > around Coxeter groups and the like that depend on any sort of > classification would be best organized using the same file > organization as what's readily there. Admittedly the name of the > module "sage.combinat.root_system", and the type_??? might be > misnomers. We can change them later if really needed. Anyway that's > transparent from the user point of view. I just looked into CartanType again. Here is the list of things that do *not* exist for complex reflection groups: C.dynkin_diagram C.cartan_matrix C.coxeter_diagram C.coxeter_matrix C.is_simply_laced This is pretty much all the information stored in CartanType. At the moment, I would prefer to do things in a different way for those. For example one could construct a CRG from a ST classification type or from those Cartan types which gives real finite reflection groups. And then having all information which are available in this general context attached to those. This is degree, codegree, fundamental_invariants, is_well_generated, is_real, is_crystallographic, cardinality, rank, ambient_space, reflections, reflecting_hyperplanes, ... maybe some more. Most of the stuff can be hardcoded as this is faster than actually computing it. For finite Coxeter groups and for Weyl groups, one could then call the methods for CRG. This gives another problem by having them for CartanTypes: there are many Cartan types which do not have degrees: affine or twisted types like BC... Do you think it is the right way to get CRG and their degrees into the context of Cartan types anyway? Salut, Christian -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
