#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:58 tscrim]:
> Do you check which definition people use when reading a paper, i.e. is
that the standard practice? (That is not a rhetorical question.) However I
think someone has read the manual, at least the first few lines, if they
found this class.
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.
> I was suggesting that as a private nested class; I'm sorry I wasn't very
clear on that. It's a lesser of two evils to me, not being in the
documentation versus being given to the user explicitly.
Sorry for misunderstanding. I'd be happy with this. I agree that
`_BasesCategory` is a good name.
> For reference, these are called nested classes, subclasses are from
inheritance.
Thanks.
> Let me also ask you this, when should a utility class be nested?
Specifically, why shouldn't the generic Iwahori-Hecke algebra be
(privately) nested?
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.
> I'm also starting to worry this code is trying to be too generic instead
of being explicit. In particular, we have two notions of abstract classes
for the bases in `_Basis` and the category.
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're also using reflection with the `getattr` which does incur a speed
penality:
We should change this then. Minor conveniences in coding should not win
over efficiency of execution I think. This use of `reflection` (again, I
didn't know it was called that:), is also used in the `specialize_to`
method, but I think this needed there...the alternative would be to
specify the basis that is specialized to, rather than the Hecke algebra,
but then you have to worry about converting to the correct basis before or
after specialization and as far as I can see you would need to use
reflection here instead so the problem doesn't go away.
Andrew
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:60>
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.
