-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Todo #1
Comments
Heads up- I am working on the second issue: Convenient constructor for Coxeter matrices working on strings, e.g. CoxeterMatrix("A2~", "F4") |
Wait, wasn't the agreement that there should be no type CoxeterMatrix?! |
@ulthiel I think Cameron means a function which returns just a plain old integer matrix. @CameronBraunstein I had one or two ideas about what should be supported in that code - it would be great to have some data objects about common groups (the finite, for instance) which stored some extra data, like the exponents of a group. That means this data would be available during tests, like I've done in https://github.com/joelgibson/CoxeterGroups.jl/blob/joel/test/runtests.jl#L41. You can maybe see a very rough sketch of what I'm aiming at in lines 70-end of https://github.com/joelgibson/CoxeterGroups.jl/blob/joel/src/CoxeterGroupData.jl#L70. I suppose |
@joelgibson regarding your last comment: As it is, having a Once one has such a type, one can then allow many ways to construct them, e.g., roughly in order of ascending generality ...
... and of course one could then also allow conversion in the other direction, at least were applicable. (I am not saying these need to be made available now, just that these all could turn up, and can be dealt with nicely and uniformly in your model, i.e.: "I approve' ;-). |
Could anyone of you define what "Coxeter data" is? Is this an isomorphism class of Coxeter systems? I guess not if it's possible to obtain the Coxeter matrix from it. So, what is it? And how is it different from Coxeter matrix (where you were against having a dedicated type)? |
@fingolfin Thanks for the feedback - I'm much more happy with a name like @ulthiel My supposed
I would be happy to keep coxeter_exponents(mat::Matrix) = coxeter_classify(mat).exponents |
Okay, so I think we want the exact same thing, I'm not yet sure though if we want it the same way. I thought that since so many things in Lie theory just depend on some discrete data (Coxeter matrix, Cartan matrix, etc.) it makes sense to implement this discrete object first and derive as much data as is known from theory (or computations) from there instead of taking the actual object (Coxeter group, Lie algebra, etc.) and compute it. So, I would say there should be structures CoxeterType for isomorphism classes of Coxeter systems (labeled in finite cases like Aₙ, Bₙ etc.; but away from finite and affine there is no good labeling which is maybe problematic to deal with....!?). And then there is CoxeterMatrix which has a CoxeterType. Also, instead of putting this into fields, why not into functions? E.g. there could be exponents(T::CoxeterType) returning the exponents etc. I think this better reflects the mathematics. But one problem I always had is how to find the isomorphism type, e.g. your function coxeter_classify(mat). In the finite and affine cases where there is a nice classification this is all okay. But away from this I don't know how to nicely represent an isomorphism type. I hope some of what I say make sense, I find it difficult to explain... Edit: A similar thing happens with complex reflection groups: most of the time I don't care about an actual model, just about the GLₙ-conjugacy type which have nice labels like G(m,p,n) and G₄...G₃₇. Here it's okay because there's a nice (labeled) classification. Edit2: One other thing I would like to do with the structures(e.g. CoxeterMatrix) is to know it's indecomposable components and derive data from putting together data from the indecomposable components. E.g. exponents(A₄ x D₆) is put together from exponents(A₄) and exponents(D₆). |
The DataType make more senses if replaced by Example of acceptables:
For finite and affine types, the type information can be useful for interactions with different structures, such as Dynkin diagram and Root System. Also, The Dynkin diagram can be added in this stage to clarify the notations of nodes. Like O---O=>=O
1 2 3
B3 For Coxeter group that is not classfied, it doesn't support the string initialization.
Possible solution: First, we divide the Dynkin diagram into its connected parts, or decompose the Cartan matrix(Coxeter matrix) into indecomposables(ref: sage), then do some standardization to match the exact type. BTW, note that @joelgibson has already done a lot of good jobs in these works, changing types might take costs and need more considerations. |
The text was updated successfully, but these errors were encountered: