#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 tscrim):
Replying to [comment:60 andrew.mathas]:
> Normally yes:). The problem in this cae is that changing the parameters
isn't simply changing the definition it is changing the algebra. The two
algebras are related by an outer automorphism, but this automorphism is
non-trivial on the T-basis so it makes everything look and behave a little
differently.
Ah I see.
> To borrow a phrase from Nicolas, the code should do the talking. Having
`_BasesCategory` nested makes the defininition of the basis classes
easier, although there is not much in it. On the other hand, the generic
Hecke algebras really are subclasses and it would be major pain, I think,
to define them as nested classes.
> Having the nested `_Basis` class together with the category was really
in the initial patch: I simply moved some common methods out of the three
basis classes into `_Basis`. All of the methods in `_Basis` really should
be inside the category but as far as I can see this is not possible.
Please correct me if I am wrong.
You are correct, concrete methods can't be overwritten by the category, in
particular the `__init__()` method.
> ... and as far as I can see you would need to use reflection here
instead so the problem doesn't go away.
Let me see what I can do.
Replying to [comment:61 andrew.mathas]:
> 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 ...?
How about `GenericHeckeAlgebra_nonstandard`, following the convention for
partitions/permutations?
> 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).
Good point. I'll add something to this effect.
Best,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:62>
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.
