Different behavior for reflections for matrix Coxeter group and Weyl groups

[tscrim]

Currently, we have the following behavior:

sage: W = CoxeterGroup(['A',1])
sage: W.reflections()
[[-1]]
sage: W = WeylGroup(['A',1])
sage: W.reflections()
Finite family {[0 1]
[1 0]: (1, -1)}

In particular, the former returns a list of elements in the group, whereas the latter returns a family whose keys are elements in the group and whose values are roots. This leads to different iterator behaviors between the two. Since Weyl groups are a subcategory of Coxeter groups, we should make this behavior consistent.

Note, this was introduced by #11010 and is specific for the matrix implementation of CoxeterGroup. We can also lift this up to the category of (finite) Coxeter groups.

CC: @sagetrac-sage-combinat @nthiery @fchapoton @stumpc5 @anneschilling @sagetrac-mshimo @darijgr @jplab @dwbump

Component: combinatorics

Keywords: coxeter groups, reflections

Author: Travis Scrimshaw

Branch/Commit: 46565ec

Reviewer: Frédéric Chapoton

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

[stumpc5]

comment:1

Hi Travis,

also in the light of hopefully having soon the chevie version of reflection groups:

• What do you think is the correct behaviour?
• Does it make sense to allow user labels of the reflections in the case of finite reflection groups? -- this might be interesting in the situation that you want to look for words in all reflections. (But that also puts another layer of possible bugs!)
  There, is is currently

sage: ReflectionGroup(['A',1]).reflections()
Finite family {0: (1,2)}
sage: ReflectionGroup(['A',1],reflection_index_set=["A"]).reflections()
Finite family {'A': (1,2)}

[nthiery]

comment:2

Oops, really, reflections does not return a collection of reflections? It makes sense to index the reflections by roots; and it can be ok to have the index set depend on the implementation, and or to return the collection as a plain list/tuple. But returning a family of roots indexed by reflections feels really weird. I am surprised I did not catch this earlier.

@stumpc5: by default I would indeed wait for a strong use case before adding a layer of complexity.

[stumpc5]

comment:3

It makes sense to index the reflections by roots

for the complex reflection groups to come, this would not make sense, so if we want to have these to have similar behaviour, such an indexing would be bad.

[tscrim]

comment:4

I think it is best to have them be consistent, which we can easily do by making CoxeterGroup.reflections return a family indexed by the reflections whose values are the roots.

With that being said, in many ways I feel that it is more natural for the family to be indexed by the roots and the values be reflections. It means we can just do for x in W.reflections() as I don't think of roots as being reflection (instead of corresponding to).

I would return a family with the keys being roots and values being reflections. Since iteration over a family is iteration over the values, this will be consistent with complex reflection groups returning a tuple (taking advantage of ducktyping). At least, I don't think of reflections having a natural total ordering, so you should only be iterating over all them.

[nthiery]

comment:5

Replying to @stumpc5:

It makes sense to index the reflections by roots

for the complex reflection groups to come, this would not make sense, so if we want to have these to have similar behaviour, such an indexing would be bad.

Agreed. I meant: it's a reasonable indexing in the above example. I guess at this point we want to leave freedom of the indexing set, and only impose that reflections return a collection of elements of the group.

[nthiery]

comment:6

Replying to @tscrim:

With that being said, in many ways I feel that it is more natural for the family to be indexed by the roots and the values be reflections. It means we can just do for x in W.reflections() as I don't think of roots as being reflection (instead of corresponding to).

I would return a family with the keys being roots and values being reflections. Since iteration over a family is iteration over the values, this will be consistent with complex reflection groups returning a tuple (taking advantage of ducktyping). At least, I don't think of reflections having a natural total ordering, so you should only be iterating over all them.

+1

[stumpc5]

comment:7

At least, I don't think of reflections having a natural total ordering

See Dyer "Hecke algebras and shellings of Bruhat intervals" for the importance of reflection orderings ;-). I usually want them to come at least in some "convex order" as in that paper...

Anyway, I am fine with giving freedom to the keys, and only force that iteration does iters through the actual reflections.

[tscrim]

Branch: public/combinat/fix_reflections_coxeter_groups-20027

[tscrim]

Author: Travis Scrimshaw

[tscrim]

comment:8

Okay, here is where I am at. I flipped the key/value order on WeylGroup.reflections(). I made CoxeterGroup.reflections() return a family. Additionally, I did some cleanup on the @cached_method returning mutable objects. This included removing the caching of positive_roots as it did not appear to be called anywhere except in roots(), which is cached, so I don't see a reason to cache it (moreover, getting the keys from a Family should be fast).

So now my questions are these:

• Do we want to issue a warning for the change in behavior for WeylGroup.reflections()? If so, how should we?
• Do we want to lift one or both of these implementations to the category (and on this ticket)?
• Do we want to implement an iterator over all reflections for infinite groups? This could be done by a RecursivelyEnumeratedSet which goes by conjugating by simple reflections corresponding to the non-descents of a given reflection.

@stumpc5 I agree that convex orders are natural and important, but we would still need a natural/canonical reduced expression for the long element. Although I guess we could use the reduced expression that gives the BZL strings (I only know this for type A_n though...), but this still feels somewhat artificial to me.

---

New commits:

90b278a	Reversing the family for reflections.
8c9b809	Making CoxeterGroup.reflections return a Family and some touchups.
2595826	Removing caching of CoxeterGroup.positive_roots().