Create a class for Coxeter matrices and types

[tscrim]

This is a partial step towards #16126, but carries the necessary information to speed up #16630 when the input is given as a finite !Cartan/Coxeter type.

It is possible to input numbers c<= -1 in the matrix to represent an infinite label, but with a different value in the bilinear form of the Tits representation.

The current implementation recognizes finite and affine types

Possible follow-up: -create an abstract class for Coxeter matrices and Cartan matrices? -Maybe change the name of CoxeterType.py could to type_coxeter.py -Recognize more types

Depends on #17990 Depends on #18152 Depends on #18743

CC: @sagetrac-sage-combinat @darijgr @fchapoton @jplab @sagetrac-vripoll @sagetrac-jmichel @nthiery @kevindilks

Component: group theory

Keywords: Coxeter groups, matrices, types, days64

Author: Travis Scrimshaw, Jean-Philippe Labbé

Branch: 5d188d4

Reviewer: Jean-Philippe Labbé, Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/17798

[tscrim]

Author: Travis Scrimshaw

[tscrim]

Description changed:

--- 
+++ 
@@ -1 +1 @@
-This is a partial step towards #16126, but carries the necessary information to speed up #16630 when the input is given as a finite Cartan/Coxeter type.
+This is a partial step towards #16126, but carries the necessary information to speed up #16630 when the input is given as a finite !Cartan/Coxeter type.

[tscrim]

comment:1

Here's a working version that implements a class CoxeterMatrix and a generic CoxeterType coming from a CartanType. I also removed some deprecated code.

---

New commits:

d31d286	Merge branch 'public/ticket/16630' of trac.sagemath.org:sage into public/combinat/coxeter_matrices-17798
1dddd20	Initial creation of the files.
1aadfbe	Merge branch 'develop' into public/combinat/coxeter_matrices-17798
f7fd3ac	Merge branch 'develop' into public/combinat/coxeter_matrices-17798
5484c5d	Making all doctests pass and removing some deprecated code.

[tscrim]

Branch: public/combinat/coxeter_matrices-17798

[tscrim]

Commit: 5484c5d

[darijgr]

comment:2

Some armchair reviewing (I am not sure if I am up to the actual job): You replaced the coxeter_matrix method on CartanType_abstract by a call to the CoxeterMatrix constructor, which is heavily ducktyped; you also removed the caching. Have you checked for speed regressions? I am also unhappy with the ducktyping since it is hard to debug. Does it makes sense to build a custom from_cartan_type constructor for CoxeterMatrix that bypasses most of the duckery?

[tscrim]

comment:3

Actually, I will re-enable that caching; there was a time when I was considering the CoxeterMatrix to be a UniqueRepresentation, but it was easier to make it a usual class. However, for (better or) worse, pythonic code is ducktyped code since it is a weakly-typed language. Yet I tried to make case-by-case as much as possible (following what I did for CartanMatrix). There is some indirection done in CoxeterMatrix by converting the Cartan type to a Coxeter type, but I felt this was the best way to do things (at least with the current implementation). Yet this part isn't ducktyped. So what my long-winded reply is saying is I'm open to suggestions, but this is the local optimal code I'm at.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 5484c5d to 311eb18

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

311eb18

Fixing a pickling issue and some easy doctest failures.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

2ef21f0	Re-enable cache of coxeter_matrix() for CartanType_abstract.
e61a4f3	Fixed import of numpy via UCF.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 311eb18 to e61a4f3

[darijgr]

comment:6

I fear I cannot be of much help with this ticket, as I don't even know the difference between a Coxeter and a Cartan type... But please simplify that CoxeterMatrix.__init__. It is so complicated it is not pythonic in any good sense of this word. Python's the weak type system should not keep us from writing constructors (e.g., from_cartan_type) tailored to specific input data. I have no idea why catch-all constructors have become a standard in Sage, but this kind of programming gave us #17124 and probably some more ugliness I don't remember.

[jplab]

comment:8

In view of the tickets #15703, #16126, tt would be very good to include the possibility to have "generalized" Coxeter matrices.

The "generalized" means that for the infinite labels, we can put a real number <= -1 in the matrix.

Of course, this may be not so natural to have Coxeter matrices with such entries, but this will make life much much easier for the other tickets: being able to start with a matrix which encodes the "geometry" behind the matrix.

Ticket #16126 should be kind of parallel to this one.

If you think it is a good idea, I would try take the patch from here and make it possible to into such values.

[jplab]

Dependencies: #17990

[tscrim]

comment:11

You can work around #17990 by explicitly specifying the base ring, but they only ring which has oo and the integers is the symbolic ring AFAIK. I think the best/long-term fix for allowing matrices with say ZZ[oo] is to construct a general parent for the ordered set R[oo] where R is any other ring (well ordered set where all things become less than infinity). Actually...you could probably use TropicalSemiring(ZZ) which does this (plus a bit more structure):

sage: T.zero()
+infinity
sage: T(2) < T.zero()
True
sage: T(2) > T.zero()
False

But the matrix space constructor requires a proper ring...which is where the real trouble probably is... I'm done rambling now.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

bdcd7a5

Dirty version added possible entry <=-1 and affine types recognition

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from e61a4f3 to bdcd7a5

[jplab]

comment:13

This is a dirty version so that you may have a look.

It includes now a classification of the affine types. I do not know exactly if this recognition algorithm was coded before. Anyways, I wrote it, it was a good exercise.

The code should be a cleaned and fully tested. Therefore I change the status to "needs_work".

If you have any suggestions, comments, I'm totally open!

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

86b2d78

Merge branch 'develop=6.6.b5' into t/17798/public/combinat/coxeter_matrices-17798

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from bdcd7a5 to 86b2d78

[jplab]

Description changed:

--- 
+++ 
@@ -1 +1,16 @@
 This is a partial step towards #16126, but carries the necessary information to speed up #16630 when the input is given as a finite !Cartan/Coxeter type.
+
+There are a few things TO DO in the current patch:
+
+- Subdivided the init into smaller methods
+- Maybe change the name of CoxeterType.py to type_coxeter?
+- Added doctests
+- Add a `__getitem__` method using the index_set
+- Remove the inheritance from matrix_generic_dense
+- add `_matrix_` method 
+- put is_finite, is_affine in attributes
+- put samples in Coxetertype
+- improve the check_coxeter_type code
+
+
+Eventually, maybe create an abstract class for Coxeter matrices and Cartan matrices?

[jplab]

Changed author from Travis Scrimshaw to Travis Scrimshaw, Jean-Philippe Labbé

[jplab]

Changed keywords from Coxeter, matrices, types to Coxeter, matrices, types, days64

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 86b2d78 to f44e52f

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

77189dd	Corrected base ring of the Coxeter matrix
f135c2e	Corrected the bilinear form method
f44e52f	Now asks for a coercion map from base ring in bilinear form

[tscrim]

comment:17

Since we are now wrapping a matrix, I think instead we should just make this either a list of lists or a dict of (i,j): val (where undefined entries are 2). That way we don't have to worry about the base ring or anything like that and we can (easily in the former case) pass that to the matrix constructor for those that want to do matrix operations. I'm actually leaning towards doing the dict method since most entires of a Coxeter matrix that people will use are 2 (at least, that's my current imagination). Thoughts?

[jplab]

comment:18

Probably a dictionary would be good. Though, we would have to write an appropriate string representation, this is not a big deal.

Adding a matrix method to Coxeter matrix may sound a bit absurd, but since the CoxeterMatrix are more or less only to stock data, I believe it is ok. We may also make it cached...

[tscrim]

comment:19

I doubt it's worth it to cache it...

Anyways, the string representation would probably be something like this (untested):

def _repr_(self):
    w = max(len(str(v)) for row in self for v in row)
    fstr = '{:>' + str(w) + '}' # should result in something like '{:>30}'
    return '\n'.join('[' + ' '.join(fstr.format(v) for v in row) + ']' for row in self)

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from f44e52f to d0932c3

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

d0932c3

Removed inheritance from matrix, added methods and attributes

[jplab]

Description changed:

--- 
+++ 
@@ -5,9 +5,9 @@
 - Subdivided the init into smaller methods
 - Maybe change the name of CoxeterType.py to type_coxeter?
 - Added doctests
-- Add a `__getitem__` method using the index_set
-- Remove the inheritance from matrix_generic_dense
-- add `_matrix_` method 
+- Add a `__getitem__` method using the index_set [X]
+- Remove the inheritance from matrix_generic_dense [X]
+- add `_matrix_` method [X]
 - put is_finite, is_affine in attributes
 - put samples in Coxetertype
 - improve the check_coxeter_type code

[jplab]

Changed keywords from Coxeter, matrices, types, days64 to Coxeter groups, matrices, types, days64

[jplab]

comment:22

Hi,

While having a look at the diff of the current patch, I saw that in CoxeterMatrixGroup the method coxeter_graph is renamed by coxeter_diagram.

I'm having thoughts about this for a while.

I would be tempted to have a clear distinction between dynkin diagram and coxeter graphs. Especially considering #16126 coming.

I guess eventually, there could be a common class on top of dynkin diagrams and coxeter graphs from which they inherit. But right now, it makes more sense to me to try to keep the convention coxeter graph vs dynkin diagram.

What do you think?

[tscrim]

comment:23

There's some danger with calling it a Coxeter graph, as this was the first entry I got when Googling: http://en.wikipedia.org/wiki/Coxeter_graph. I don't believe this is what we want, and I believe the more common terminology is Coxeter diagram. This was my mistake in calling that method Coxeter graph, which I did without thinking/looking too much because it returns a Graph instance.

+1 for refactoring out common code between Coxeter and Dynkin diagrams, but IMO it doesn't need to be done here as we have #16126.

[jplab]

comment:24

Yes... It is a bummer that Coxeter does have a graph with its actual name tagged to it!

In the end, it is just a name, I guess we should try to be consistent in the naming convention since we are at it, and I'd like to know how to proceed...

As far as I know, Humphreys is careful not to give the graphs a name. On p.1 of Bjoerner&Brenti, they call it a "Coxeter graph (or Coxeter diagram)".

I would vote for Coxeter graph and Dynkin diagram since it emphasizes the difference between the two structures. About the confusion with the actual Coxeter graph, I believe it is not a so dreadful danger of confusion.

I think that the Coxeter graph is not so commonly used as to need it directly from the sage prompt, right?

Agreed with refactor common code later.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

df3c69a	Merge branch 6.7.beta3 into cox_matrices_trac
764667e	Corrected coding conventions
f830a53	Made is_finite and is_affine attributes
823c8f2	Added the rank as an attribute
a5afb94	Subdivided the init (from matrix, graph, coxeter type)
d352639	Added some tests

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from d0932c3 to d352639

[jplab]

Description changed:

--- 
+++ 
@@ -2,15 +2,16 @@

 There are a few things TO DO in the current patch:

-- Subdivided the init into smaller methods
+- Subdivided the init into smaller methods [X]
 - Maybe change the name of CoxeterType.py to type_coxeter?
 - Added doctests
 - Add a `__getitem__` method using the index_set [X]
+- Check that the getitem method works
+- Add a __ eq __ method to CoxeterType
 - Remove the inheritance from matrix_generic_dense [X]
 - add `_matrix_` method [X]
-- put is_finite, is_affine in attributes
+- put is_finite, is_affine in attributes [X]
 - put samples in Coxetertype
 - improve the check_coxeter_type code

-
 Eventually, maybe create an abstract class for Coxeter matrices and Cartan matrices?

[jplab]

comment:26

Hi,

So I pushed some commits I did today.

There is still a lot to do, but it's progressing.

I tested the files and there were many tests that failed. I noticed that many of them fail because we removed the inheritance from matrices that was providing with equality tests.

I continue the coding... Don't hesitated if you have comments or suggestions!

[jplab]

Changed dependencies from #17990 to #17990, #18152

[jplab]

comment:27

Hi,

Where should the function samples be placed?

If I put it in the abstract class CoxeterType, it complains that it should be called on an instance.

JP

[nthiery]

comment:28

Replying to @jplab:

Where should the function samples be placed?

If I put it in the abstract class CoxeterType, it complains that it should be called on an instance.

It should be a staticmethod or classmethod..

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

25a6f54	Added some values in the dictionnary of the matrix
03b24b4	Edited the check coxeter type function
532afda	Added a samples method to CoxeterType
d018e28	Added samples and made many tests pass
fb77b78	PEP8 conventions

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from d352639 to fb77b78

[jplab]

comment:30

Hi,

Now all test passes on the file coxeter_matrix, not on coxeter_type (3 failure caused by the old UCF implementation, I did not bother trying to correct them because of the new implementation in #18152). When it is going to be merged in a beta, I'll verify again.

The sample is supposed to contain all finite and affine coxeter types plus some more infinite types which are not affine.

I believe now the next step would be to go through the methods to double check that tests verify well the code.

About the renaming of the CoxeterType file to type_coxeter, I believe it is better to keep it as it is now since it is similar to cartan_type.py

[jplab]

Description changed:

--- 
+++ 
@@ -5,13 +5,14 @@
 - Subdivided the init into smaller methods [X]
 - Maybe change the name of CoxeterType.py to type_coxeter?
 - Added doctests
-- Add a `__getitem__` method using the index_set [X]
-- Check that the getitem method works
-- Add a __ eq __ method to CoxeterType
+- Add a getitem method using the index_set [X]
+- Check that the getitem method works [X]
+- Add a eq method to CoxeterMatrix [X]
 - Remove the inheritance from matrix_generic_dense [X]
 - add `_matrix_` method [X]
 - put is_finite, is_affine in attributes [X]
-- put samples in Coxetertype
-- improve the check_coxeter_type code
+- put samples in Coxetertype and CoxeterMatrix [X]
+- improve the check_coxeter_type code [X]

-Eventually, maybe create an abstract class for Coxeter matrices and Cartan matrices?
+Possible follow-up:
+-create an abstract class for Coxeter matrices and Cartan matrices?

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

3262e43	Added tests
a3c76fa	Merge branch 'sage-6.8.beta2' into cox_matrices_trac
f2be73c	Made tests pass in coxeter_type

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from fb77b78 to f2be73c

[jplab]

Description changed:

--- 
+++ 
@@ -1,18 +1,12 @@
 This is a partial step towards #16126, but carries the necessary information to speed up #16630 when the input is given as a finite !Cartan/Coxeter type.

-There are a few things TO DO in the current patch:
+It is possible to input numbers c<= -1 in the matrix to represent an infinite label, but with a different value in the bilinear form of the Tits representation.

-- Subdivided the init into smaller methods [X]
-- Maybe change the name of CoxeterType.py to type_coxeter?
-- Added doctests
-- Add a getitem method using the index_set [X]
-- Check that the getitem method works [X]
-- Add a eq method to CoxeterMatrix [X]
-- Remove the inheritance from matrix_generic_dense [X]
-- add `_matrix_` method [X]
-- put is_finite, is_affine in attributes [X]
-- put samples in Coxetertype and CoxeterMatrix [X]
-- improve the check_coxeter_type code [X]
+The current implementation recognizes finite and affine types

 Possible follow-up:
 -create an abstract class for Coxeter matrices and Cartan matrices?
+-Maybe change the name of CoxeterType.py could to type_coxeter.py
+-Recognize more types
+
+

[jplab]

comment:32

All tests pass on sage-6.8.beta2.

I would say that this version is ready for review.