Hi Christian!
Sorry for being slow ... heavy teaching load + papers to finish ...
And thanks for pushing this forward!
On Fri, Oct 08, 2010 at 04:14:13PM -0700, Christian Stump wrote:
> > 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...
Yup. There is no definitive choice between porting from Chevie or
calling Chevie. That's a case by case decision depending on the
computational constraints, and convenience. In any cases, we should be
careful to reuse the vast amount of expertise there! Having Jean
around is a great asset.
> 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...
Yes. That's why CartanTypes are organized in a hierarchy of classes,
so that not all cartan types need to have the same methods.
Altogether, I am just advocating having all classification objects
(dynkin diagrams, coxeter matrices, named "cartan types" like A_3, ST
classification types, possibly the CRG diagrams you mention in the
other mail, ...) be handled uniformly as a single hierarchy of classes
with something like "ClassificationObject" as top class (generalizing
the current hierarchy which just has "CartanType" as top).
Having such an architecture makes everything very flexible. Each class
can decide independently whether and how it handles each feature
(rank/degrees/...), by just inheriting something generic (multiple
inheritance is a great feature here), or providing a method for
recalculating it, or providing a method hardcoding it, or anything in
between ... And it avoids ugly run time type checking.
Putting each named classification object in a file like type_E.py
makes it further easy for the users and developers to retrieve
everything that was hardcoded, or not, for type E. Which is basically
what Chevie does.
Typical design question: do we want to make a distinction between a
complex reflection group ComplexReflectionGroup(m,p,n) from the
corresponding classification object G(m,p,n)? If not, should
ComplexReflectionGroup be part of the hierarchy of classification
objects? I often thought about putting weyl groups, root systems, and
the like in the CartanType hierarchy.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <[email protected]>
http://Nicolas.Thiery.name/
--
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.
