Sage: Ticket #19830: Classification of finite and affine Coxeter groups
https://trac.sagemath.org/ticket/19830
<p>
The bug here is two-fold:
</p>
<ol><li>The roots for a <code>CoxeterGroup</code> are constructed as in Humphreys "in the Coxeter sense, that all have the same norm". Therefore it seems more natural to not at all introduce a type C and to follow Humphrey's classification of finite Coxeter groups given on page 32.
</li></ol><ol start="2"><li>The current implementation of types B/C (which I suggest to remove and to only keep type B) is also broken:
</li></ol><ul><li>First Sage start
<pre class="wiki">sage: W = CoxeterGroup(['B',4])
sage: W.coxeter_matrix().coxeter_type()
Coxeter type of ['B', 4]
sage: W = CoxeterGroup(['C',4])
sage: W.coxeter_matrix().coxeter_type()
Coxeter type of ['B', 4]
</pre></li><li>Second Sage start
<pre class="wiki">sage: W = CoxeterGroup(['C',4])
sage: W.coxeter_matrix().coxeter_type()
Coxeter type of ['C', 4]
sage: W = CoxeterGroup(['B',4])
sage: W.coxeter_matrix().coxeter_type()
Coxeter type of ['C', 4]
</pre></li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/19830
Trac 1.1.6stumpc5Mon, 04 Jan 2016 13:15:21 GMT
https://trac.sagemath.org/ticket/19830#comment:1
https://trac.sagemath.org/ticket/19830#comment:1
<p>
And what to do with
</p>
<pre class="wiki">sage: CoxeterGroup(CoxeterType(['B',2],['B',2]).coxeter_matrix()).coxeter_matrix().coxeter_type()
Coxeter type of G2xG2 relabelled by {1: 3, 2: 4}
</pre>
TickettscrimMon, 04 Jan 2016 13:21:40 GMT
https://trac.sagemath.org/ticket/19830#comment:2
https://trac.sagemath.org/ticket/19830#comment:2
<p>
With <code>7.0.beta1</code>, I get:
</p>
<pre class="wiki">sage: CoxeterGroup(CoxeterType(['B',2],['B',2]).coxeter_matrix()).coxeter_matrix().coxeter_type()
Coxeter type of B2xB2
</pre><p>
What are you using when you tested that? Although, that you got that in any situation is very frightening to me.
</p>
Ticketstumpc5Mon, 04 Jan 2016 14:29:55 GMT
https://trac.sagemath.org/ticket/19830#comment:3
https://trac.sagemath.org/ticket/19830#comment:3
<p>
Hm, after restarting with <code>7.0.beta2</code> I also get this result, and I wasn't able to reproduce the bug even after retyping all comments that seemed to be related. So let's leave this aside for now.
</p>
Ticketstumpc5Mon, 04 Jan 2016 14:33:23 GMT
https://trac.sagemath.org/ticket/19830#comment:4
https://trac.sagemath.org/ticket/19830#comment:4
<p>
At some point during that session I accidentally copied almost the complete source of <code>subword_complex.py</code> into the terminal. So it might also be that this caused the issue, though I wouldn't know how.)
</p>
Ticketstumpc5Mon, 04 Jan 2016 15:40:24 GMT
https://trac.sagemath.org/ticket/19830#comment:5
https://trac.sagemath.org/ticket/19830#comment:5
<p>
@tscrim: And what to do with
</p>
<pre class="wiki">sage: sage: W = CoxeterGroup(['B',3],index_set=['A','b','XX'])
sage: sage: W.index_set()
(1, 2, 3)
</pre>
Ticketstumpc5Tue, 05 Jan 2016 15:12:28 GMT
https://trac.sagemath.org/ticket/19830#comment:6
https://trac.sagemath.org/ticket/19830#comment:6
<p>
Sorry for adding more and more questions here: The documentation of the method <code>roots</code> states
</p>
<pre class="wiki">These are roots in the Coxeter sense, that all have the
same norm. They are given by their coefficients in the
base of simple roots, also taken to have all the same
norm.
</pre><p>
How is this true if the sum of the coefficients is not one? As in
</p>
<pre class="wiki">sage: W = CoxeterGroup(['A',2])
sage: W.roots()
[(1, 0), (1, 1), (0, 1), (-1, 0), (-1, -1), (0, -1)]
</pre>
TicketchapotonTue, 05 Jan 2016 15:17:20 GMT
https://trac.sagemath.org/ticket/19830#comment:7
https://trac.sagemath.org/ticket/19830#comment:7
<p>
What ? Type A2 is simply laced, so the roots are just the roots in the Weyl sense..
</p>
<p>
The scalar product is the one that is invariant by the group, of course..
</p>
TickettscrimTue, 05 Jan 2016 15:26:10 GMT
https://trac.sagemath.org/ticket/19830#comment:8
https://trac.sagemath.org/ticket/19830#comment:8
<p>
I am working on trying to fix the norm index set issue, which uncovered some other bugs/isues with the relabelling. I was somewhat inclined to say that passing a Coxeter (or Cartan) type and an index set was essentially double info, but after some more thought, I think it is a nice API to support.
</p>
Ticketstumpc5Tue, 05 Jan 2016 15:30:39 GMT
https://trac.sagemath.org/ticket/19830#comment:9
https://trac.sagemath.org/ticket/19830#comment:9
<p>
@chapoton: My last comment on the root lengths was too quick, please forget about it and sorry for the noise!
</p>
TicketnthieryTue, 05 Jan 2016 20:51:12 GMT
https://trac.sagemath.org/ticket/19830#comment:10
https://trac.sagemath.org/ticket/19830#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/19830#comment:6" title="Comment 6">stumpc5</a>:
</p>
<blockquote class="citation">
<p>
Sorry for adding more and more questions here: The documentation of the method <code>roots</code> states
</p>
<pre class="wiki">These are roots in the Coxeter sense, that all have the
same norm. They are given by their coefficients in the
base of simple roots, also taken to have all the same
norm.
</pre><p>
How is this true if the sum of the coefficients is not one? As in
</p>
<pre class="wiki">sage: W = CoxeterGroup(['A',2])
sage: W.roots()
[(1, 0), (1, 1), (0, 1), (-1, 0), (-1, -1), (0, -1)]
</pre></blockquote>
<p>
Isn't this just that the basis of the simple roots is not orthonormal? So one can't read of the norm of vectors expressed there right away.
</p>
TicketnthieryTue, 05 Jan 2016 20:52:49 GMT
https://trac.sagemath.org/ticket/19830#comment:11
https://trac.sagemath.org/ticket/19830#comment:11
<p>
Oops, I was too quick and did not see your last comment :-)
</p>
TickettscrimSat, 30 Jan 2016 01:20:01 GMTcc, milestone changed; commit, branch, author set
https://trac.sagemath.org/ticket/19830#comment:12
https://trac.sagemath.org/ticket/19830#comment:12
<ul>
<li><strong>cc</strong>
<em>darij</em> added
</li>
<li><strong>commit</strong>
set to <em>d86d0abf581635109f147bc3b75c7efb0d819899</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-7.0</em> to <em>sage-7.1</em>
</li>
<li><strong>branch</strong>
set to <em>public/combinat/fix_coxeter_type_relabelling-19830</em>
</li>
<li><strong>author</strong>
set to <em>Travis Scrimshaw</em>
</li>
</ul>
<p>
Here is a fix for relabelling issues that I came across. Although I think this might be better on a separate ticket.
</p>
<p>
@darij the previous test for checking for relabelled types gave false negatives. Consider F<sub>4</sub> under cyclic shift and under interchanging 1 and 3. These are the <em>same</em> type and our relabelling check does not distinguish between them (nor can any algorithm).
</p>
<p>
How do we want to handle Coxeter vs Dynkin classification of the affine types or the general case? I'm guessing for the affine types, we just use the untwisted types. Do we even want to consider the general case at this point?
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d86d0abf581635109f147bc3b75c7efb0d819899"><span class="icon"></span>d86d0ab</a></td><td><code>Improving support for relabelled Coxeter types.</code>
</td></tr></table>
TicketdarijSat, 30 Jan 2016 01:25:11 GMT
https://trac.sagemath.org/ticket/19830#comment:13
https://trac.sagemath.org/ticket/19830#comment:13
<p>
Oh gosh, I have literally no idea about anything beyond the classical types. Is this a bug in the algorithm I wrote? I thought very little of that algorithm is still in Sage?
</p>
TickettscrimSat, 30 Jan 2016 01:44:05 GMT
https://trac.sagemath.org/ticket/19830#comment:14
https://trac.sagemath.org/ticket/19830#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/19830#comment:13" title="Comment 13">darij</a>:
</p>
<blockquote class="citation">
<p>
Oh gosh, I have literally no idea about anything beyond the classical types. Is this a bug in the algorithm I wrote? I thought very little of that algorithm is still in Sage?
</p>
</blockquote>
<p>
Sorry, I meant the B/C issue in the ticket description.
</p>
TicketdarijSat, 30 Jan 2016 01:55:29 GMT
https://trac.sagemath.org/ticket/19830#comment:15
https://trac.sagemath.org/ticket/19830#comment:15
<p>
Oh, that!
</p>
<p>
I have to admit I don't know what the current recognition code is doing (the path-dependent output suggests some caching is going on), but my original code in <a class="closed ticket" href="https://trac.sagemath.org/ticket/16630" title="defect: Fix category for finite Coxeter groups (closed: fixed)">#16630</a> never outputted a C_n. Maybe we should do the same?
</p>
TickettscrimSat, 30 Jan 2016 02:06:40 GMT
https://trac.sagemath.org/ticket/19830#comment:16
https://trac.sagemath.org/ticket/19830#comment:16
<p>
The B/C issue isn't so much having to do with type recognition (which won't result in a C<sub>n</sub>), but instead what to do when we do things like <code>CoxeterType(['C', 5])</code>.
</p>
Ticket