#14261: Iwahori-Hecke algebra with several bases
-------------------------------------+-------------------------------------
Reporter: brant | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.13
Component: combinatorics | Resolution:
Keywords: Iwahori Hecke | Merged in:
algebra | Reviewers: Andrew Mathas, Brant
Authors: Brant Jones, | Jones, Travis Scrimshaw
Travis Scrimshaw, Andrew Mathas | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: #13735 #14014 |
#14678 #14516 |
-------------------------------------+-------------------------------------
Changes (by {'newvalue': u'Brant Jones, Travis Scrimshaw, Andrew Mathas',
'oldvalue': u'Brant Jones, Travis Scrimshaw'}):
* author: Brant Jones, Travis Scrimshaw => Brant Jones, Travis Scrimshaw,
Andrew Mathas
Comment:
I've finally finished this "review". I had intended just to give the code
a quick look over and then a positive review but the issues with computing
the KL-bases in the non-generic cases changed that. For example, the
previous version of the patch would have computed KL-bases for ZW which
were not the expected bases. There were also some issues with
documentation (both what was and wasn't written and the fact that it
wasn't included in the reference manual) and places where Laurent
polynomials were misbehaving badly...and I didn't like the way that it was
necessary to specify the Hecke parameters and their square roots.
To fix all of these issues I ended up rewriting the patch completely
(sorry!). As I foreshadowed above, the KL-bases are now done behind the
scenes in a generic Hecke algebra. There is no longer any need to specify
square roots as the code just figures out what to do. Here is an exerpt
from the new documentation:
{{{
The conversions to and from the Kazhdan-Lusztig bases are done behind
the
scenes whenever the Kazhdan-Lusztig bases are well-defined. Once a
suitable
Iwahori-Hecke algebra is defined they will work without further
intervention.
For example, with the "standard parameters", so that
`(T_r-q^2)(T_r+1)=0`::
sage: R.<q> = LaurentPolynomialRing(ZZ)
sage: H = IwahoriHeckeAlgebra('A3', q^2)
sage: T=H.T(); Cp= H.Cp(); C=H.C()
sage: C(T[1])
q*C[1] + q^2
sage: Cp(T[1,2,1])
q^3*Cp[1,2,1] + (-q^2)*Cp[1,2] + (-q^2)*Cp[2,1] + q*Cp[1] +
q*Cp[2] + (-1)
sage: C(_)
q^3*C[1,2,1] + q^4*C[1,2] + q^4*C[2,1] + q^5*C[1] + q^5*C[2] + q^6
With the "normalized presentation, so that `(T_r-q)(T_r+q^{-1})=0`::
sage: R.<q> = LaurentPolynomialRing(ZZ)
sage: H = IwahoriHeckeAlgebra('A3', q,-q^-1)
sage: T=H.T(); Cp= H.Cp(); C=H.C()
sage: C(T[1])
C[1] + q
sage: Cp(T[1,2,1])
Cp[1,2,1] + (-q^-1)*Cp[1,2] + (-q^-1)*Cp[2,1] + (q^-2)*Cp[1] +
(q^-2)*Cp[2] + (-q^-3)
sage: C(_)
C[1,2,1] + q*C[1,2] + q*C[2,1] + q^2*C[1] + q^2*C[2] + q^3
In the group algebra, so that `(T_r-1)(T_r+1)=0`::
sage: H = IwahoriHeckeAlgebra('A3', 1)
sage: T=H.T(); Cp= H.Cp(); C=H.C()
sage: C(T[1])
C[1] + 1
sage: Cp(T[1,2,1])
Cp[1,2,1] - Cp[1,2] - Cp[2,1] + Cp[1] + Cp[2] - 1
sage: C(_)
C[1,2,1] + C[1,2] + C[2,1] + C[1] + C[2] + 1
On the other hand, if the Kazhdan-Lusztig bases are not well-defined
(when
``-q_1q_2`` is not a square), attempting to use the Kazhdan-usztig
bases
triggers an error::
sage: R.<q>=LaurentPolynomialRing(ZZ)
sage: H = IwahoriHeckeAlgebra('A3', q)
sage: C=H.C()
Traceback (most recent call last):
...
ValueError: The Kazhdan_Lusztig bases are defined only when the
product of the parameters are a square root
}}}
In terms of the code there is now a new ``_AGenericIwahoriHeckeAlgebra``
class which is where all of the KL-basis calculations are really done.
Elements of this class have a ``specialize_to`` method for getting back to
the (possibly non-generic) Hecke algebra. The transition to the category
framework is now complete with the previous element class
``IwahoriHeckeAlgebraElement`` being subsumed into the
``IwahoriHeckeAlgebra`` class. There is also a new
``normalized_laurent_polynomial`` function for making Laurent polynomials
(and even integers) play more nicely...this seems like an awful hack, but
it does seem to be necessary? (Perhaps Travis' Laurent polynomial patch
removes the need for this, but things like 1/1 being rational may still
cause problems?).
I have been through the documentation and tried to explain everything. I
apologise for the many typos that I have no doubt introduced and I hope
that what remains is passable.
One question/concern: if some one wants to work with what really is a
generic Hecke algebra, say defined over ``Z[q,q^-1]``, I wonder whether
the overhead in implementing the KL-bases via a hidden two variable Hecke
algebra will end up being too costly. If I could see a way to detect when
the parameters really are "generic" then perhaps a generic Hecke algebra
could be returned in this case to avoid the duplication....but I can't for
the life of me see how to detect this. Perhaps the special parameters
``(q_1,q_2)=(q1,-1)`` and ``(q_1,q_2)=(q,q^-1)`` should be treated
separately?
Finally, I seem to have confused my local version of the combinat queue so
I am unable to push the patch to the combinat server at the moment.
Instead I'll upload the patch to trac and hope that it works -- it should
be applied **after** the two patches currently in the queue. Two more
points:
* Nicolas suggested passing in the ``bar_involution`` as a parameter to
the Hecke algebras. I haven't done this. I can't think of a case where
this would be needed, but perhap it is? Whether or not this is done, the
``bar_involution`` should give an error/warning whenever the parameters
are not generic as in such caes it ill return silly results. (As I said,
however, I dont see how to test for "generic" parameters...perhaps just
algebraic independence overhe ground ring?).
* Travis, sorry, but I haven't looked at all at your ``term_cmp`` patch.
Andrew
ps Given the size of the my review patch I've added myself as an author on
the ticket. My changes definitely need to be reviewed!
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:52>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
