Dne neděle, 6. října 2013 22:07:11 UTC+2 Nicolas M. Thiery napsal(a):
>
>         Dear Vít, 
>
> On Sun, Oct 06, 2013 at 11:03:38AM -0700, Vít Tuček wrote: 
> >     I have implemented an algorithm for computing the minimal 
> representatives 
> >    of cosets W/W_S where W is the Weyl group of a Lie algebra and W_S is 
> the 
> >    Weyl group of its standard Levi subalgebra corresponding to the set 
> of 
> >    simple roots S. These posets have their place well established in the 
> >    literature, e.g. they govern nilpotent Lie algebra cohomology of 
> >    finite-dimensional modules and homomorphisms of (generalized) Verma 
> >    modules. I use my routines for producing illustrations in my work and 
> for 
> >    checking theorems in low dimensions. 
> >    I would like this code to be included into sage but I am a bit unsure 
> >    about the API. Right now I have implemented methods of WeylGroup 
> >    class parabolic_bruhat_graph(self, Levi_indices) 
> >    and  parabolic_poset(self, Levi_indices) which are basically just 
> wrappers 
> >    over _minimal_representatives(self,Levi_indices). 
> >    Sometimes it is convenient (and is quite common in the literature) to 
> >    specify the Levi part by the simple roots which are NOT contained in 
> its 
> >    root system. Should this be implemented in the API as well? 
> >    On a related note, each standard parabolic subalgebra determines a 
> >    (symmetric) grading on the Lie algebra (g = g_{-k} \oplus \cdots g_l) 
> and 
> >    any such grading determines a parabolic subalgebra. I have 
> implemented 
> >    method for RootSpace which splits the positive roots into the graded 
> >    components, i.e. the result is a dictionary {j : g_j } Could this be 
> >    included as well? 
>
> Thanks for offering to share your code! 
>

Thanks for comments! :)
 

>
> Just some quick remarks to get started: the minimal representatives 
> themselves are already available for any Coxeter group as 
> "coset_representatives": 
>
>                 sage: W = SymmetricGroup(4) 
>                 sage: WI = W.coset_representatives([1,2], side="right") 
>                 sage: WI.cardinality() 
>                 4 
>
> Is the first part of your contribution about those, or about building 
> the bruhat order on those coset representatives? In the later case, 
> are you using "coset_representatives" to get the elements themselves? 
>

Actually, my first code with which I produced some graphics for my poster 
was using coset_representatives, but it was too slow for E_6, since I 
traversed the whole W. I've used algorithm that appeared e.g. in Baston, 
Eastwood: The Penrose Transform: Its Interaction With Representation Theory 
or Cap, Slovak: Parabolic geometries. I suspect this algorithm appeared 
earlier in some algebraic literature. It is based on the fact that the Weyl 
group W acts transitively on delta_p (defined bellow) with stabilizer W_S. 
The steps of the algorithm are as follows:

1. Let delta_p be the sum of fundamental weights that correspond to the 
crossed nodes of the Dynkin diagram (i.e. to those simple roots that are 
not in the parabolic).
2. Form the orbit of delta_p under simple reflections. Only 
simple_reflections corresponding to positive coefficients need to be 
applied (thus terminate when all coefficients are nonpositive). For each 
weight in the orbit remember the simple_reflection that was used to obtain 
it.

This orbit is actually a subposet of the poset we want. The weights in the 
orbit are in bijective correspondence with the poset representatives. Just 
multiply the simple_reflections from delta_p to your weight. 

3. Compute the Bruhat order relation e.g. using something like w <= w' iff 
w = w's_alpha. (This step could be done more efficiently by computing the 
saturated subsets of positive roots that correspond to the representatives. 
 But I'm not sure if its worth the additional complexity.)
 

>
> For the user interface, a natural choice could be to add the feature 
> to the existing bruhat_poset method of FiniteCoxeterGroups: 
>
>         sage: W.bruhat_poset(index_set=[1,2,4]) 
>
> This would be consistent with the syntax for the quantum_bruhat_graph 
> method of WeylGroups. Here, I am assuming your algorithm work for any 
> (finite) Coxeter group, right? 
>

Yeah, I'll just need to pass to the associated RootSpace.
 

>
> Further comments anyone? 
>
> For the positive roots: the system already knows that there is a grading: 
>
>     sage: W = CoxeterGroups().example() 
>     sage: R = RootSystem(["A",3]).root_lattice() 
>     sage: R.positive_roots() 
>     <sage.combinat.backtrack.TransitiveIdealGraded instance at 0x7992440> 
>
> What's really missing is to upgrade TransitiveIdealGraded so that one 
> can easily ask for all elements of a given depth. See also the related 
> ticket http://trac.sagemath.org/ticket/6637. 
>

I'm talking about something different here. Given a standard parabolic 
subalgebra p_S, there is always a so called grading element in the center 
of the Levi part of p_S. (Basically its just the dual of delta_p.) This 
grading element acts by integers on the Lie algebra and when you split the 
algebra into the eigenspaces of this grading element you get a grading 

g = g_{-k} \oplus \cdots \oplus g_k

such that g_0 is the Levi part and g_0 \oplus \cdots \oplus g_k is your 
parabolic p_S. On the other hand, given such a grading you can define the 
parabolic by g_0 \oplus \cdots \oplus g_k and prove that it induces the 
same grading you have started with. These gradings (and associated 
filtrations) are studied in differential geometry, the buzzwords being 
"filtered manifolds" and "subRiemannian geometry", although the latter is 
quite more general. 
 

>
> >    In some areas of mathematics it is customary to actually draw these 
> posets 
> >    with nodes replaced by labelled Dynkin diagrams with nodes not 
> >    corresponding to the Levi part crossed. See 
> >    e.g. http://arxiv.org/abs/1303.1307 
> >    I haven't looked into graph drawing of sage nor at Dynkin diagrams, 
> but in 
> >    case this feature also has a chance to be included in sage I am 
> willing to 
> >    try to implement it. 
>
> It should not be too hard indeed! 
>
> >    I'll post patches as soon as I get properly acquainted with sage 
> >    patch & build system. 
>
> Which is in a state of flux, since we are currently switching 
> development workflow (including a switch from mercurial to git). 
> See: http://trac.sagemath.org/ticket/13015 
>
>
I'm glad to see this. I guess I should just base my patches on the upcoming 
5.12 and use the old way?
 

> Cheers, 
>                                 Nicolas 
> -- 
> Nicolas M. Thiéry "Isil" <nth...@users.sf.net <javascript:>> 
> http://Nicolas.Thiery.name/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to