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.