Opened 8 years ago
Last modified 7 years ago
#16126 new enhancement
Introduce a class for generalized Coxeter graphs
Reported by:  JeanPhilippe Labbé  Owned by:  JeanPhilippe Labbé 

Priority:  major  Milestone:  sage6.10 
Component:  combinatorics  Keywords:  coxeter, graphs, days57 
Cc:  Vivien Ripoll, Nicolas M. Thiéry, Frédéric Chapoton, Sage Combinat CC user, Kannappan Sampath  Merged in:  
Authors:  JeanPhilippe Labbé  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  u/jipilab/ticket16126 (Commits, GitHub, GitLab)  Commit:  8cf2af9e2363366692857eeb91c4f4c14eabe46f 
Dependencies:  #17798  Stopgaps: 
Description
Coxeter graphs are undirected graph without multiedges with possibly labeled edges within the set {4,5,...,oo}. Coxeter graphs encode Coxeter systems. A Coxeter system is a group presented with a special set of generators.
To represent a Coxeter group, one can use the canonical geometric representation, see Chapter 5 of Humphreys for instance. In this representation, the group acts faithfully on a vector space and preserves a canonical bilinear form.
For infinite Coxeter groups, it is useful to allow a more general bilinear form, which still gives a faithful representation and has the advantage that every reflection subgroup is represented as a general geometric representation.
These more general representations can be encoded into a generalized Coxeter graph where labels "oo" can be replaced by any real number $c <= 1$. The case $c=1$ represents the canonical choice, in this case one can keep the label "oo".
The class for generalized Coxeter graphs will be based on the class DynkinDiagram? and adapted for its purposes.
Change History (11)
comment:1 Changed 8 years ago by
Milestone:  sage6.2 → sage6.3 

comment:2 Changed 8 years ago by
Milestone:  sage6.3 → sage6.4 

comment:3 Changed 8 years ago by
Cc:  Kannappan Sampath added 

comment:4 Changed 7 years ago by
Dependencies:  → #17798 

comment:5 Changed 7 years ago by
Milestone:  sage6.4 → sage6.10 

comment:6 Changed 7 years ago by
Hi, Yes, for sure!
I already have some old initial code. I haven't looked at it for a while, but I will push it in the next few days.
comment:7 Changed 7 years ago by
Branch:  → u/jipilab/ticket16126 

comment:8 Changed 7 years ago by
Commit:  → c0ac5a4c0669fdb7e16338048dbc98568facb49f 

Owner:  set to JeanPhilippe Labbé 
Here is a first "very dirty version" of the patch.
Basically, everything is still to be looked over...
This is just for you to have a look. I will continue in more detail soon enough.
New commits:
f2f84eb  Initial commit: added the file coxeter_graph.py

6a2e20c  Some minor changes to start the patch

987aefc  Merge branch 'ticket16126' into newticket16126

afd5e59  Added necessary startup files

9b135a5  Changed the occurences of Dynkin to Coxeter

c0ac5a4  Made some Cartan to Coxeter

comment:9 Changed 7 years ago by
Authors:  → JeanPhilippe Labbé 

comment:10 Changed 7 years ago by
Commit:  c0ac5a4c0669fdb7e16338048dbc98568facb49f → 8cf2af9e2363366692857eeb91c4f4c14eabe46f 

comment:11 Changed 7 years ago by
Some more broken edits.
No need to give comments yet... There is still too many things to look after. I just push so you have an overview.
I will come up with a DOTO list for the ticket once things are a bit less messy.
Basically, I decided to follow the structure of CoxeterMatrix? instead of DynkinDiagrams?... This requires a lot a adaptation and overall modification of everything...
Basically, it seems to me that hardcoding the graphs is the best way to go. From there... everything should go through...
I'm still learning a lot how the structure goes. But it seems that DynkinDiagrams? should also be somehow reengineered so that it fits better?!
Basically, once we have CoxeterGraph? and CoxeterMatrix? up and running, the next logic step would be to have a parent type for CoxeterGraph?DynkinDiagram? and then for CoxeterMatrix?, CartanMatrix?. But this is for later...
Now that #17798 is merged, we should get to work on this next. JeanPhilippe, do you have any (partial) code for this?