adding is_coxeter_element to finite coxeter groups

[fchapoton]

to allow using noncrossing partition lattices for Weyl groups

CC: @tscrim @darijgr @stumpc5

Component: combinatorics

Author: Frédéric Chapoton

Branch/Commit: fd788b7

Reviewer: Christian Stump, Travis Scrimshaw

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

[fchapoton]

Branch: u/chapoton/23230

[fchapoton]

Commit: 9d8abde

[fchapoton]

New commits:

9d8abde

adding is_coxeter_element method to finite coxeter groups

[stumpc5]

comment:2

The check

    self.absolute_length() == self.parent().rank()

does not seem enough to test for Coxeter elements. E.g., in type B already there are elements with this property that are not Coxeter elements. The most general version of Coxeter element would need to test that such an element has an eigenvalue that is a primitive h-th root of unity where h is the Coxeter number.

[fchapoton]

comment:3

aargh, I am such a type-A-only guy..

[stumpc5]

comment:4

I think it would be better to remove the is_coxeter_element call from the noncrossing_partition_lattice method, or at least only call it if available.

[fchapoton]

comment:5

What about

return self in prod(W.gens()).conjugacy_class()

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

Changed commit from 9d8abde to a7ac3ee

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

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

a7ac3ee

better check for is_coxeter_element

[stumpc5]

comment:7

An alternative would be

                if self.is_real() or (hasattr(c,"is_coxeter_element") and c.is_coxeter_element()):
                    smart_covers = in_unitary_group = True

                R = self.reflections()
                if L is None:
                    L = self.elements_below_coxeter_element(c=c)
#                    if c.is_coxeter_element():
#                        smart_covers = in_unitary_group = True

but yours is fine, too!

---

New commits:

a7ac3ee

better check for is_coxeter_element

[stumpc5]

comment:8

To use more generic code, it'd vote for using

return self in self.parent().coxeter_elements()

[tscrim]

comment:9

What about back to basics:

wd = self.reduced_word()
I = self.parent().index_set()
return len(wd) == len(I) and set(wd) == set(I)  # Really this is just checking it is a permutation of I

This should also work for all Coxeter groups.

[stumpc5]

comment:10

Well, this works but doesn't check whether an element is a Coxeter element :-)

Here are some definitions:

1. A standard Coxeter element is the product of the generators in some order

   2a. A Coxeter element is an element that is conjugate to a standard Coxeter element.

   2b. This is equivalent to : A Coxeter element is an element for that has eigenvalue e^{2\pi i / h} where h is the Coxeter number.

Given the alternative description in 2, this condition can be relaxed to:

2c. A Coxeter element is an element that has a primitive h-th root of unity as an eigenvalue.

This can be shown to be equivalent to

2d. A Coxeter element is an element that is obtained from a standard Coxeter element by conjugation and Galois automorphisms.

For Weyl groups, 2a - 2d are all equivalent, while one can show that in general, there are k conjugacy classes of Coxeter elements where k is the degree of the field extension of the field of definition over QQ. You find all these notions in my paper arxiv.org/abs/1404.5522 with Vic Reiner and Vivien Ripoll.

[tscrim]

comment:11

Oh, I see. I only learned what you call standard Coxeter elements.

[fchapoton]

comment:12

We are talking here about finite Coxeter groups, so Travis method should be ok.

I do not care here about general complex reflection groups.

EDIT: well, maybe not, after all..

[fchapoton]

comment:13

So this boils down to a terminology problem. What do we call a Coxeter element in sage ?

[stumpc5]

comment:14

I think it is standard to call a Coxeter element an element that is conjugate to the product of the generators. This is also what's implemented in

categories/finite_complex_reflection_groups.py

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

Changed commit from a7ac3ee to 37df024

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

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

37df024

trac 23230 suggested way

[fchapoton]

comment:16

ok, guys. Does this suit you ?

[tscrim]

comment:17

Replying to @fchapoton:

So this boils down to a terminology problem. What do we call a Coxeter element in sage ?

This might just be my lack of properly learning the terminology as I've learned the product of all generators is a Coxeter element and that all Coxeter elements are conjugate (stated more as a fact rather than a definition.

Actually, you might want edit Wikipedia:

A Coxeter element is a product of all simple reflections. The product depends on the order in which they are taken, but different orderings produce conjugate elements, which have the same order.

I don't really care about the terminology, so standard Coxeter elements for the above and the conjugacy class being Coxeter elements is good with me. Although we should make sure we explain things in our documentation more than anything.

[stumpc5]

Changed branch from u/chapoton/23230 to u/stumpc5/23230

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

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

87796e4

added definitions of coxeter elements to the methods is_coxeter_element in finite_coxeter_groups and in reflection_group_complex

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

Changed commit from 37df024 to 87796e4

[stumpc5]

comment:20

I added the definitions to the docs -- unfortunately, my make doc failed (after the make build went through) so I cannot test whether I made mistakes in the doc strings, which I likely do as I never remember how to properly typeset it.

[tscrim]

comment:21

It looks okay overall, but you might be getting problems with latex and \p being converted by Python as an escaped character. Anytime I put any latex in a docstring, I make sure it is raw, so it starts r""" (or a single line r") (and overall in Sage because of how we do our documentation, you probably want to do this for any docstring).

Also, you might want to use

-:meth:`sage.categories.finite_complex_reflection_groups.coxeter_elements`
+:meth:`~sage.categories.finite_complex_reflection_groups.coxeter_elements`

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

Changed commit from 87796e4 to fd788b7

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

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

fd788b7

added travis' suggestions

[tscrim]

comment:23

IIRC, there was another method that added an `e^{2\pi i/h}` that was not marked raw.

[1adc0eef-8957-46d9-975b-2dd71dfbd9ba]

comment:24

It may be worth pointing out that for a general Coxeter group, the "standard Coxeter elements" (ie, product of all simple reflections in some order) are only guaranteed to be conjugate if the Coxeter diagram is acyclic. This will of course be true for the finite case we're considering here, but notably, it doesn't extend to type A affine.

---

New commits:

fd788b7

added travis' suggestions

[stumpc5]

comment:25

Replying to @tscrim:

IIRC, there was another method that added an `e^{2\pi i/h}` that was not marked raw.

sorry, I don't find it.

[fchapoton]

comment:26

as far as I can tell, it already has the r""" mark.

[fchapoton]

comment:27

bot is green (but does not check the pdf build)

[stumpc5]

comment:28

Replying to @fchapoton:

bot is green (but does not check the pdf build)

I cannot build the doc for reasons I don't want to investigate - from my side the ticket is good to go, so @tscrim, please give it a positive review if you agree!

[tscrim]

Reviewer: Christian Stump, Travis Scrimshaw

[tscrim]

comment:29

Ah, sorry, I must have misread it. Good to go.

[vbraun]

Changed branch from u/stumpc5/23230 to fd788b7