Closed fchapoton closed 7 years ago
Branch: u/chapoton/23230
New commits:
9d8abde | adding is_coxeter_element method to finite coxeter groups |
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.
aargh, I am such a type-A-only guy..
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.
What about
return self in prod(W.gens()).conjugacy_class()
Branch pushed to git repo; I updated commit sha1. New commits:
a7ac3ee | better check for is_coxeter_element |
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 |
To use more generic code, it'd vote for using
return self in self.parent().coxeter_elements()
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.
Well, this works but doesn't check whether an element is a Coxeter element :-)
Here are some definitions:
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.
Oh, I see. I only learned what you call standard Coxeter elements.
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..
So this boils down to a terminology problem. What do we call a Coxeter element in sage ?
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
Branch pushed to git repo; I updated commit sha1. New commits:
37df024 | trac 23230 suggested way |
ok, guys. Does this suit you ?
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.
Changed branch from u/chapoton/23230 to u/stumpc5/23230
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 |
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.
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`
Branch pushed to git repo; I updated commit sha1. New commits:
fd788b7 | added travis' suggestions |
IIRC, there was another method that added an `e^{2\pi i/h}`
that was not marked raw.
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 |
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.
as far as I can tell, it already has the r"""
mark.
bot is green (but does not check the pdf build)
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!
Reviewer: Christian Stump, Travis Scrimshaw
Ah, sorry, I must have misread it. Good to go.
Changed branch from u/stumpc5/23230 to fd788b7
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