-
-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding upper and lower Bruhat cones of M. Dyer to sage/combinat/root_system/reflection_group_real.py #32669
Comments
Commit: |
comment:5
would examples with WeylGroup or CoxeterGroup work ? |
comment:6
The method reflection_to_positive_root() is used. As far as I saw neither WeylGroup nor CoxeterGroup has this method. WeylGroup has furthermore no method to obtain roots roots. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:10
in Weyl Groups, there is
|
comment:11
I see. Then writing a similar method for Weyl Groups should be possible using reflection_to_root() and then to_ambient() |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:14
Thank you for your contribuation. I have a rather long list of comments. Most of them are minor issues I think. A green bot unfortunatly only means that you added the optional tags correctly, as the bots don't have gap3 installed.
Those lines need some work.
Yes, I know that you did not introduce this ultra-long line, but it is still good to fix it, when touching.
+ For ``side`` = ``'upper'``: ``s_beta`` ``x`` covers ``x`` and ``x`` <= ``s_beta`` ``x`` <= ``y``.
+
+ For ``side`` = ``'lower'``: ``y`` covers ``s_beta`` ``y`` and ``x`` <= ``s_beta`` ``y`` <= ``y``. I don't know what it means. What are those things called:
There are also other failing doctests discovered, because people apparently do not test
However, you did not cause this I think. If we don't fix them here (which definitely needs not to happen), which should open a ticket for them.
- roots = [self.reflection_to_positive_root(x*r*x.inverse()) for z, r in x.bruhat_upper_covers_reflections() if z.bruhat_le(y)]
+ roots = [self.reflection_to_positive_root(x * r * x.inverse())
+ for z, r in x.bruhat_upper_covers_reflections()
+ if z.bruhat_le(y)]
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:45
Replying to @DennisJahn:
Now it should have worked. There are only two entries in the list of commits, one for each modified file. |
comment:46
thanks. Now, I see a lot of code duplication with the existing implementation in Weyl groups found in
In my opinion, it is desirable and should be possible to have only one common implementation. |
comment:47
Replying to @fchapoton:
I would agree but I think we had this discussion already. I can' find it anymore though. The only parent/super category in common is coxeter groups and there is no implementation of roots or the cartan matrix in there. Furthermore the implementation of roots in Weyl groups is very different from the one in reflection groups. I currently have no idea how to combine these worlds. |
comment:48
This is still done at the category level, so there should be some other implementation not relying on I don’t understand the point you are making about the implementation of the roots. The data is well-defined and the root systems are isomorphic. I agree with @fchapoton that we should have one common code that is agnostic to the choice of implementation. If things are not melding together properly, then we need to look at the code and unify it somehow. Then there is an issue with the permutation implementation about either its internal consistency or with the generic implementation that needs to be fixed. This would sweep the issue under the rug. |
comment:49
Replying to @tscrim:
The implementation for Weyl groups is done in
at the category level, yes.
what is, if I understand correctly, not at the catagory level. Furthermore, I think, the only super category in common is CoxeterGroups. So my question/problem is: Where should an implementation of 'Bruhat cones' be done such that both, Weyl groups and reflection groups, can use it?
I did not dive fully into this function. It wasn't working and all the other, similar functions used the side='right' flag. So I tried that and then it worked... |
comment:50
Dear Travis and Frederic, @tscrim, @fchapoton: Dennis is about to finish his thesis and I would like this code to go in! I do not understand your points that this should go into the category level because neither Coxeter groups (finite or not) or complex reflection groups there come with a root system attached. This code heavily uses root systems, so this is needed. WeylGroups have this at the category level, that's why it worked for these. Best, |
Reviewer: Frédéric Chapoton |
comment:51
oh, well. Let's move on. Let me note that to still depend on gap3 in 2022 is a bit sad. |
comment:52
Thanks Frederic!
I agree, but Jean Michel is porting it to julia (https://github.com/jmichel7/Gapjm.jl). Once this is done, we can move there! |
comment:53
Well, this does not sound like really good news to me. |
comment:54
I just have some little doc things though before merging it in: Please move the references to the master reference file and roughly follow the format there. - - ``x`` - an element in the group `W`
-
- - ``y`` - an element in the group `W`
-
- - ``side`` (default: ``'upper'``) -- must be one of the following:
+ - ``x`` -- an element in the group `W`
+ - ``y`` — an element in the group `W`
+ - ``side`` — (default: ``'upper'``) must be one of the following: |
comment:57
Thank you. |
Changed reviewer from Frédéric Chapoton to Frédéric Chapoton, Travis Scrimshaw |
To a pair of elements x,y in a Coxeter group W one can associate two polyhedral cones. The 'upper bruhat cone' generated by all roots beta such that s_beta * x covers x and s_beta * x <= y and similarly the 'lower bruhat cone' generated by all beta sucht that y covers s_beta * y and x <= s_beta * y .
These cones were used in https://eudml.org/doc/174610 and https://arxiv.org/abs/2103.03715
CC: @tscrim
Component: combinatorics
Keywords: Coxeter groups, reflection groups, Bruhat order, Bruhat cones
Author: Dennis Jahn
Branch/Commit:
648e634
Reviewer: Frédéric Chapoton, Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/32669
The text was updated successfully, but these errors were encountered: