#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 |
-------------------------------------+-------------------------------------
Comment (by andrew.mathas):
Replying to [comment:59 nthiery]:
> About AGenericIwahoriHeckeAlgebra:
>
> - +1 on ``it should not be in the global name space''
>
> - +1 on ``it should not be in the Hecke algebra name space (i.e. appear
in the tab completion on Hecke algebra'')
>
> - +1 on it appearing *somewhere* in the reference manual
>
> With this in mind, I guess I would put it in the same module as it is
now, but not as a nested class. And maybe change the class name to be
explicit about the choice of parameters not being what people would call
``the generic ones''?
OK, so Anne and I have voted against putting it in the manual, Travis has
voted for and Nicolas for but with the caveat that it should (probably)
have a different name. If the name suggests that this is an unusual
generic Hecke algebra and we put a `.. warning` in the manual I guess I'd
be happy. What about calling it `AnUnusualGenericHeckeAlgebra` or
`ANonStandardGenericHeckeAlgebra` or ...?
> Oh, and a stupid idea: would it make any sense for the Hecke algebra to
have lift/retract maps to the "generic" one, and reference the later as
"ambient" like we do for subquotients ?
Well, it is not a subquotient and mathematically I wouldn't describe it as
an ''ambient'' space, so I don't think that this is very intuitive
terminology.
On the other hand, there is already a map from the generic Hecke algebras
to the non-generic one given by the `specialize_to` method:
{{{#!python
sage: R.<a,b>=LaurentPolynomialRing(ZZ,2)
sage: H=IwahoriHeckeAlgebra("A3",a^2,-b^2)
sage: GH=H._generic_iwahori_hecke_algebra
sage: GH.T()(GH.C()[1])
(v^-1)*T[1] + (-u*v^-1)
sage: ( GH.T()(GH.C()[1]) ).specialize_to(H)
(a^-1*b^-1)*T[1] + (-a*b^-1)
}}}
Perhaps this could be defined explicitly as a map or coercion? Although
since these classes are not ''supposed'' to be used directly I am not sure
if this is really necessary. If there there isn't any overhead in doing
this it wouldn't hurt. There isn't a well-defined ''retract'' map in the
other direction.
Btw, the `specialize_to` map probably should be a normal method of the
Iwahori-Hecke algebra elements. It won't always be well-defined, and it is
not clear how to test for when it is well-defined, but the documentation
for the method could have a warning to this effect and we could raise an
exception when specialization fails. (Actually, we should add a similar
warning for the bar involution `bar`).
Andrew
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:61>
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.
