Salut, > 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.
I do not yet understand your idea of having this hierarchy of classes. What is the advantage for multiple classification objects to have the common ancestor "ClassificationObject"? I do understand that it might be good to know where to find hard coded data for all the objects we are talking about. Also, I think that it might get chaotic (in the negative sense) to attach properties to an object just because you can define this property for another object with the "same" classification type. Two examples: - in the implementation of cluster algebras, we have a class for classifying cluster algebras and quivers. There are as well Cartan- Killing types. But why should they have attached a degree? The same the other way round, why having the size of the mutation class of a given quiver attached to a Coxeter group? - sometimes, the properties are even contradictory: the rank of the Coxeter group of affine type A_n is given by n+1, whereas its rank as a Weyl group is n (because the reflection representation as a Coxeter group has dim n+1, while the reflection representation as a Weyl group has dim n). I think I am still missing a central point in your ideas! > > 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. I thought of the following: you have a class ComplexReflectionGroup having all properties you think of, including a classification_type. And then, it could as well have methods to_CoxeterGroup() returning the CoxeterGroup of this type if possible and an error saying there is no Coxeter group of this type otherwise. The only objects (I see at the moment) which I would handle in a hierarchy are CoxeterGroup containing FiniteCoxeterGroup containing WeylGroup, and CoxeterGroup containing as well AffineCoxeterGroup containing AffineWeylGroup, and CoxeterGroups containing HyperbolicCoxeterGroups. But having CoxeterGroups and (finite) ComplexReflectionGroups, they have FiniteCoxeterGroups as an overlap, but beside this, they behave very different (think of hyperbolic Coxeter groups or even worse). I would suggest, we set up a skype meeting these days and discuss all this on the phone! Best, 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.
