#14261: Iwahori-Hecke algebra with several bases
-------------------------------------+-------------------------------------
Reporter: brant | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Keywords: Iwahori Hecke | Merged in:
algebra | Reviewers: Andrew Mathas, Brant
Authors: Brant Jones, | Jones, Travis Scrimshaw
Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: #13735 #14014 |
#14678 #14516 |
-------------------------------------+-------------------------------------
Comment (by andrew.mathas):
Replying to [comment:39 nthiery]:
> So one could imagine a similar approach where: if the user wants the
> full featured Hecke algebra, (s)he would have to provide explicitly a
> method implementing the bar involution on the ground field (assuming
> of course it actually makes sense!).
Hi Nicolas,
Unfortunatey, having user supplied bar involution isn't going to work
here. For example, it makes perfect sense to talk about the Kazhdan-
Lusztig bases of the group ring `ZW` (by specialisation) BUT you can can't
define an appropriate bar involution on `ZW`. The point is that you can't
detect the KL-bases inside `ZW`: to find them you have to work generically
and then specialise -- that is, you have to work in a completely different
(but related) algebra to define these bases.
It turns out that if you have a Hecke algebra with quadratic relations of
the form
{{{
(T_r-a)(T_r-b)=0
}}}
such that the square root of `-ab` is a well-defined element of the ground
ring then this Hecke algebra has well-defined Kazhdan-Lusztig bases (not
sure if this is written down anywhere but, nonetheless, it is true).
To define the KL-bases one has to go to a suitable generic suitation and
then specialize. One way of doing this is to work with the Hecke algebra
defined over the Laurent polynomial ring `Z[u,u^-1,v,v^-1]` which has
quadratic relations
{{{
(T_r-u)(T_r+v^2u^-1)=0
}}}
and then specialize `u` to `a` and `v` to `\sqrt{-ab}` -- so that,
`-v^2/u` maps to `b`. There is a bar involution on this "generic" Hecke
algebra which sends `u` to `u^-1`, `v` to `v^-1` and `T_w` to
`T_{w^{-1}}^{-1}`. Moreover, there are bar invariant bases `{C_w}` and
`{C'_w}` which are unique subject to a Kazhdan and Lusztig like property.
Implementing the KL-basis via this strange two parameter generic Hecke
algebra behind the scenes means that the KL-bases will be defined for
`ZW`. In addition, the KL-basis will automatically work correctly if I
consider the Hecke algebra which has quadratric relations of the form
`(T_r-v^2)(T_r+1)=0` or of the form `(T_r-v)(T_r+v^{-1})=0`. From the
user's point of view they will get the right bases in all of thesse cases,
and more, without them needing to do anything special.
In principle I have a patch which impements this approach, but I am
running into a strange inheritance issue which I don't understand. In the
original patch we have an implementation of the Iwahori-Hecke algebra `H`,
with parameters `a=q1` and `b=q2`, using the standard structure:
{{{#!python
class IwahoriHeckeAlgebra(Parent, UniqueRepresentation):
class T(CombinatorialFreeModule, BindableClass):
class Element(CombinatorialFreeModuleElement):
class _KLHeckeBasis(CombinatorialFreeModule, BindableClass):
class C_prime(_KLHeckeBasis):
def to_T_basis(self, w):
....
class C(_KLHeckeBasis):
}}}
Whenever the squareroot of `-ab` is well-defined I am attaching a "generic
Hecke algebra" `GH` to `H` together with Kazhdan-Lusztig `C` and `C'`
bases which are computed generically in `GH` then automatically
specialised back to `H`. As the methods for converting between the KL-
basis in the two `H` and `GH` are different I have created another class
for the generic Hecke algebra which looks like:
{{{
class _AGenericIwahoriHeckeAlgebra(IwahoriHeckeAlgebra):
class T(IwahoriHeckeAlgebra.T):
class Element(CombinatorialFreeModuleElement):
class C_prime(IwahoriHeckeAlgebra.C_prime):
def to_T_basis(self, w):
....
class C(IwahoriHeckeAlgebra.C_prime):
}}}
In principle, what is supposed to happen is that everything inherits from
`IwahoriHeckeAlgebras` and I just overwrite the basis conversion functions
-- and a few other things. Everything is working exactly as I expect
EXCEPT that when a "generic" method already exists in a "non-generic"
basis class then it is NOT overriding the corresponding method in
`IwahoriHeckeAlgebra`.
For example, as above, the 'C_prime' basis classes of `H` and `GH` both
contain a method `to_T_basis`. The method in `GH` implicitly calls the
corresponding method in `GH` and then specialises the result back to `H`.
The corresponding generic method for `GH` implements the inductive
construction of the `C'`-basis in terms of the `T`-basis. For some reason,
however, both of these `to_T_basis` methods are the method defined in
`IwahoriHeckeAlegbras` and the new method in `_AGenericIahoriHeckeAlgebra`
is being ignored.
The categories etc of the various different Hecke algebras and bases all
appear to be correct (and they are different for the generic and non-
generic versions). I am just getting the wrong methods in the generic
bases. Other "generic" methods which do not have "non-generic"
counterparts, such as specialization, are working fine.
I suspect that I am running foul of the category framework somewhere and
that it doesn't like the way that am trying to use inheritance above. Can
anyone tell me what I am doing wrong and what I should be doing?
Andrew
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:40>
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.
