Todo

[ulthiel]

• Structure for Coxeter matrices
• Convenient constructor for Coxeter matrices working on strings, e.g. CoxeterMatrix("A2~", "F4") or something like this
• Coxeter groups should be substructure of AbstractAlgebra groups (similar for elements), and CoxeterGroup{T} should be a parametric type where T specifies the algorithm to be used (I think the latter is a good idea but open for suggestions)
• Implement algorithm based on geometric realization (see implementation and documentation by J. Gibson @joelgibson)
• Implement minimal roots algorithms by Casselman
• Tests

[CameronBraunstein]

Heads up- I am working on the second issue: Convenient constructor for Coxeter matrices working on strings, e.g. CoxeterMatrix("A2~", "F4")

[ulthiel]

Wait, wasn't the agreement that there should be no type CoxeterMatrix?!

[joelgibson]

@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 coxeter_matrix("A4") would then become a synonym for coxeter_matrix(coxeter_data("A4")) internally, where coxeter_data() is the function returning the data object.

[fingolfin]

@joelgibson regarding your last comment: As it is, having a CoxterData type seems like a better idea than a CoxeterMatrix. If one can get the matrix via coxeter_matrix(cdata) that seems fine. I see you call the underlying struct CoxType -- I would advise against that, as there are also objects called CoxRings. Better to not abbreviate, spell it out. But of course CoxeterType has also drawbacks -- while it fits mathematical conventions, in this context the problem is that Type of course already has a second meaning. So perhaps CoxeterData or CoxeterTypeData or so would be better.

Once one has such a type, one can then allow many ways to construct them, e.g., roughly in order of ascending generality ...

• from strings like "A4" or even "A4 x D3"
• from a graph (!), possible with edge labels
• from a Coxeter matrix
• from a (generalized) Cartan matrix
• from root data

... 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' ;-).

[ulthiel]

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)?

[joelgibson]

@fingolfin Thanks for the feedback - I'm much more happy with a name like CoxeterData or CoxeterTypeData.

@ulthiel My supposed CoxeterData type is in bijection with Coxeter matrices, it just carries extra data which is known from classification: some data I would want to end up in there is isomorphism class (eg "A4 x D6"), finiteness, Coxeter number, exponents, order of the group. So, why do this rather than just sticking with Coxeter matrices?

1. We have a complete classification of finite and affine Coxeter systems - let's leverage this. We can fix a convention (type B has the double bond at the start, for instance), and write down everything we know for the connected Coxeter systems. A potential classification function then just has to map an arbitrary Coxeter matrix into this convention, extract the data we've written down, and relabel it across whatever bijection takes the matrix to our convention. Hence we get a nice way of extending this information to any Coxeter system of known type.
2. It allows us to get going quickly - for instance a simple test of a Coxeter group implementation (which has already proved useful while I was writing code) is to try to generate all group elements, then make sure you got the write number. This means we need to know how many we're meant to get. I've found CoxeterData-like things pretty invaluable for testing in the past.
3. It gives a useful return type for the classification function, and it clearly defines what a classification function needs to do, which is essentially to find a mapping of the input indices into our conventions.

I would be happy to keep CoxeterData as an implementation detail for now and see how it goes. I imagine a function which eats a Coxeter matrix and outputs a list of exponents would be implemented like this:

coxeter_exponents(mat::Matrix) = coxeter_classify(mat).exponents

[ulthiel]

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₆).

[RexWzh]

(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....!?).

The DataType make more senses if replaced by CartanType, just like in sage.
Ref: source code and docs of CartanType.(Contains only type information)

Example of acceptables:

• "A2 x B2" for irreducible types
• A~1, ['A', 1,1] for affine types
• I2(m), H3 for other finite cases(Non-crystallographic Cartan types in sage)

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.

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.

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.