Opened 7 years ago

Last modified 5 years ago

#16126 new enhancement

Introduce a class for generalized Coxeter graphs

Reported by: jipilab Owned by: jipilab
Priority: major Milestone: sage-6.10
Component: combinatorics Keywords: coxeter, graphs, days57
Cc: vripoll, nthiery, chapoton, sage-combinat, knsam Merged in:
Authors: Jean-Philippe Labbé Reviewers:
Report Upstream: N/A Work issues:
Branch: u/jipilab/ticket16126 (Commits) 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 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:2 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:3 Changed 6 years ago by knsam

  • Cc knsam added

comment:4 Changed 6 years ago by jipilab

  • Dependencies set to #17798

comment:5 Changed 5 years ago by tscrim

  • Milestone changed from sage-6.4 to sage-6.10

Now that #17798 is merged, we should get to work on this next. Jean-Philippe, do you have any (partial) code for this?

comment:6 Changed 5 years ago by jipilab

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 5 years ago by jipilab

  • Branch set to u/jipilab/ticket16126

comment:8 Changed 5 years ago by jipilab

  • Commit set to c0ac5a4c0669fdb7e16338048dbc98568facb49f
  • Owner changed from (none) to jipilab

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:

f2f84ebInitial commit: added the file coxeter_graph.py
6a2e20cSome minor changes to start the patch
987aefcMerge branch 'ticket16126' into newticket16126
afd5e59Added necessary startup files
9b135a5Changed the occurences of Dynkin to Coxeter
c0ac5a4Made some Cartan to Coxeter

comment:9 Changed 5 years ago by chapoton

  • Authors set to Jean-Philippe Labbé

comment:10 Changed 5 years ago by git

  • Commit changed from c0ac5a4c0669fdb7e16338048dbc98568facb49f to 8cf2af9e2363366692857eeb91c4f4c14eabe46f

Branch pushed to git repo; I updated commit sha1. New commits:

2975f1cSome partial broken edits
8cf2af9Changed each type to construct a Coxeter graph

comment:11 Changed 5 years ago by jipilab

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 re-engineered 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...

Note: See TracTickets for help on using tickets.