I have created ticket http://trac.sagemath.org/ticket/15272 and uploaded
the patch for posets & graphs.
Dne pondělí, 7. října 2013 11:39:52 UTC+2 Vít Tuček napsal(a):
>
>
>
> 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>
>> 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.
