#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):
Hey Andrew,
Replying to [comment:56 andrew.mathas]:
> I think that we disagree, which is fine:) However, this means that we
need some one (Anne, Brant, Nicolas, ...) to express an opinion so that we
can reach a decision!
I agree that we disagree. :P I would like to hear other's opinions as
well.
> I am sure that there are but the main reason that I gave against doing
this is that thie generic Hecke algebra class is very likely to confuse
people and encourage them to make mistakes.
>
> ...
>
> On the other hand, people will almost certainly want to work with the
"standard" generic Hecke algebras (with parameters `(q^2,-1)` or
`(q,q^-1)`) and it is quite likely that they will think that this class
provides that. I agree that the documentation explains what this class
actually does, but not everyone reads the manual cover-to-cover.
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.
> To my mind making this class public is a lose-lose situation: we provide
something that most people won't want and we risk confusing them because
it sounds like, but isn't something they do want. I don't see any gains.
There are very few classes in Sage which are private, and they all inherit
from `object` or `SageObject` and are small helper classes with no outside
context. The reason why I made `_KLHeckeBases` a private nested class was
because I was having difficulty with the inheritance with nested classes.
> I didn't say we were poluting the global namespace, just the namespace:)
You said sage's namespace which to me implies the global namespace.
However you're always adding it to some namespace, and pollution, as I
think of it, occurs when using tab completion. So by having it accessible
as an attribute, it's pollution.
> Whether it is private or public it's still a name that must be reserved
in sage and "maintained" further down the track - just like the current
patch needs to depreciate, and define pickle override for,
`IwahoriHeckeAlgebraT`.
I've been told we only need to do that for things imported into the global
namespace, although that doesn't mean we shouldn't formally deprecate
everything IMO. Yet we still have the same responsibilities with nested
classes because we still need to properly handle those pickles (in essence
it is in the global namespace).
> I'm against creating the category class as a separate class - I don't
care what it is called:) - so I don't see this as midde ground. Given that
you are arguing for documenting the generic Hecke algebra code I am
surprised that you're suggesting that this could be a private (and hence
undocumented) class.
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.
> Ultimately, I don't see any benefits in making the class separate, but I
think it is semantcally better to define it as a subclass and, more
importantly, doing this makes the code cleaner.
For reference, these are called nested classes, subclasses are from
inheritance. I think this makes the code harder to read since there's more
levels of indentation to fight through.
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?
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. You're also using reflection
with the `getattr` which does incur a speed penality:
{{{
sage: class Foo:
....: def bar(self):
....: return 5
sage: F = Foo()
sage: %timeit F.bar()
1000000 loops, best of 3: 796 ns per loop
sage: %timeit F.bar()
100000 loops, best of 3: 757 ns per loop
sage: %timeit F.bar()
1000000 loops, best of 3: 787 ns per loop
sage: s = 'bar'
sage: %timeit getattr(F, s)()
1000000 loops, best of 3: 1.09 us per loop
sage: %timeit getattr(F, s)()
1000000 loops, best of 3: 1.1 us per loop
sage: %timeit getattr(F, s)()
1000000 loops, best of 3: 1.11 us per loop
}}}
With this I'm more split on what is best here since it costs CPU cycles
and is less explicit, but it is more compact and an extendable idiom (i.e.
works as we add other bases, but if we keep it, there should be a comment
about what's needed for it to work).
I've probably given more than a nickle's worth, so I'll stop now before I
go broke.
Best,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:58>
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.
