Dear Andrew, Anne, Brant, Dan, On Sat, Jan 02, 2010 at 10:12:45PM -0800, Daniel Bump wrote: > I have revised both the Kazhdan-Lusztig polynomial and Iwahori > Hecke algebra patches and reposted them on the trac server. > > http://trac.sagemath.org/sage_trac/ticket/7729 > http://trac.sagemath.org/sage_trac/ticket/7751 > > Things that should be in coxeter.py have been moved there, > cached methods are used when appropriate, and both patches > work with LaurentPolynomialRings. The patches seem to me > to be fairly mature and I hope someone will review them.
Excellent, thanks much! I'll try to do that shortly, unless Andrew, Anne, or Brant beat me to it. > There are a couple of things that could be added. If both patches > are used, one may implement the Kazhdan-Lusztig basis of the Iwahori > Hecke algebra very easily. That's cool. > There is a catch, which is that as Kazhdan and Lusztig described > these bases (there are actually two, denoted C and C') one needs a > square root of q. This can be avoided by multiplying C_w by > q^(-w.length()/2) which means that it is not quite invariant by the > involution. I did not add this since it depends on both patches, but > these bases are quite important. One also wants the Kazhdan-Lusztig > involution but I did not put that in either, though it is easy. What happens if we consider the Hecke algebra with the two parameters q1 and q2 so that (T_i-q_1)(T_i-q_2) = 0? Can we express everything in terms of q_1 and q_2 without square roots, and then recover the usual KL polynomials by substituting q_1 and q_2 by q^-1/2 and q^1/2 or something like this? In practice, this would mean that the implementation of the KL polynomials would be made entirely in term of q_1 and q_2, leaving the responsibility of choosing an appropriate field containing a square root of q to the user (or some wrapper). Alain Lascoux strongly recommended to me implementing everything about Hecke algebras in terms of q_1 and q_2 because: - It is more symmetric - All the other normalizations can be trivially recovered. So a user can work with his/her own preferred normalization by just specifying appropriate values for q_1 and q_2 (possibly with wrappers/default values for the usual cases). I am completely fuzzy in the context of KL polynomials, but that strategy worked really well for me in other contexts. We may actually want to go a step further, and allow for a different pair q_1(i),q_2(i) of parameter for each i. > For affine Weyl groups, there is another thing which can be > implemented, which is the Bernstein-Zelevinsky presentation. Yes! > This involves two things, one easy and one hard. The easy one is the > subalgebra which is the Iwahori Hecke algebra of the finite > classical Weyl group. The other, which is a little trickier is a map > from the coweight lattice into the affine Hecke algebra. I have done > some experiments with this but just for type A2. If the coweight is > the negative of a dominant weight its image is a basis element, but > if it is not, it can be slow to compute. We needed those at some point two years ago, and used the signed alcove walk formula to compute them (equation (3.2.10) of Macdonald's book on affine hecke algebra; see also equation (15) of http://arxiv.org/abs/0804.3781 for the formula with q_1 and q_2). That was in MuPAD though; see HGAT::AffineHeckeAlgebraEmbedding in: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/EXAMPLES/HeckeGroupAlgebra.mu (sorry, pretty experimental and messy) In Sage, the alcove walk routines are essentially there, so it should be just a question of implementing the formula. See: - signs_of_alcovewalk in Sage 4.3: sage: L = RootSystem(['C',2,1]).weight_lattice() sage: L.signs_of_alcovewalk([1,2,0,1,2,1,2,0,1,2]) [-1, -1, 1, -1, 1, 1, 1, 1, 1, 1] sage: L = RootSystem(['A',2,1]).weight_lattice() sage: L.signs_of_alcovewalk([0,1,2,1,2,0,1,2,0,1,2,0]) [1, 1, 1, 1, -1, 1, -1, 1, -1, 1, -1, 1] - reduced_word_of_translation in reduced_word_of_translations-nt.patch: sage: R = RootSystem(["A",2,1]).weight_lattice() sage: alpha = R.simple_roots() sage: R.reduced_word_of_translation(alpha[1]) [0, 2, 0, 1] sage: R.reduced_word_of_translation(alpha[2]) [0, 1, 0, 2] sage: R.reduced_word_of_translation(alpha[0]) The later patch is not yet submitted because of some normalization issues in the twisted cases. Anne needed this feature last Fall, but we did not manage to resolve the issues over e-mail, and decided to postpone the topic until we met again face to face (April). If you have the occasion to meet her before that, maybe you could resolve this together? > Many things have to be done differently in the two cases where the > base ring is a field or a LaurentPolynomialRing. At places I had to > work around the peculiarities of LaurentPolynomialRings. For > example, unlike polynomials they have no truncate method. Ok. I very much hope that those issues will vanish by using q_1 and q_2, or that they can be resolved by fixing LaurentPolynomialRing instead. > And here is a bug, I think: > > sage: R.<q> = LaurentPolynomialRing(QQ) > sage: type(q) > <type 'sage.rings.polynomial.laurent_polynomial.LaurentPolynomial_mpair'> > sage: R(q) > q > > So far so good, but the following raises an exception: > > sage: type(q^(-1)) > <type 'sage.rings.polynomial.laurent_polynomial.LaurentPolynomial_mpair'> > sage: R(q^(-1)) > TypeError: Unable to coerce q^-1 (<type > 'sage.rings.polynomial.laurent_polynomial.LaurentPolynomial_mpair'>) to > Rational Definitely a bug. Please post a ticket, as I have zero familiarity with Laurent polynomial rings in Sage. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" <nthi...@users.sf.net> http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
