#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:54 andrew.mathas]:
> Thanks for doing this Travis and, in particular, for fixing my mistakes!
>
> > * changed `_AGenericIwahoriHeckeAlgebra` to
`GenericIwahoriHeckeAlgebra` since it is a more natural name and to allow
it to be seen in the documentation,
>
> I ''strongly'' feel that this class should not be public and it should
not be included in the documentation. My reason for this is that unless
people really know what they are doing (and probably even if they do) they
should not be calling this class directly because it will probably not
behave as they expect.
>
> By making this class public and advertising it in the documentation I
think that we will only be encouraging people to make a mistake. I
intentionally made this class a private class for precisely these reasons.
There are many instances of internal/helper classes being in the sage
documentation. For example, the `*Element` classes. They are there for
people to look at as a nice reference. Additionally this class should be
faster than going through the specialization process; so the person who is
using a generic Hecke algebra and needs to speed can know of this class's
existence. Plus IMO all objects, including private functions/methods,
should be in the reference manual. We only make it private to hide it from
the casual user using tab-completion. Since the class is not imported into
the global namespace but is key for the Hecke algebras, I'd rather see it
in the documentation.
> In terms of names, I called this '''A'''`GenenericIwahoriHeckeAlgebra`
because it returns a generic Hecke algebra with a particularly
''idiosyncratic'' choice of parameters: `u` and `-v^2/u`. There is
(currently) no way to change these parameters. Most people would expect
the two variable generic Hecke algebra to have parameters `u` and `v` and
to be defined over the Laurent polynomial ring in these indeterminates.
This is not what this class returns. For these reasons, whether or not the
class is private, I think that calling the class
`GenericIwahoriHeckeAlgebra` is misleading and will cause confusion.
>
> This class is intended as a helper class for the real Hecke algebras. It
should not be used directly. By putting it in the documentation we will
only confuse people because they will think that they should use the
generic class when they want to work with a generic Hecke algebra. When
they try to do this however they will get a rude surprise because they
will not be able to work with their preferred parameters.
You've chosen a convention for the generic Hecke algebra that is
convenient for the code here and is clearly documented. Being much closer
to naming conventions seems better to me and less likely to cause
confusion for anyone who wants/needs the generic code.
> > I'm not completely in favor of having the bases category accessible
from the `IwahoriHeckeAlgebra` instance (which does follow `QSym`) since
the category should be behind the scene as far as `IwahoriHeckeAlgebra` is
concerned and I would expect `Bases` to return a list of bases (up to the
mismatch with convention). I'd prefer to have it as its own separate
class, but I'd like to get opinions on the matter first.
>
> I prefer to have the category class as subclass of the algebra class. As
you say this structure is already used in several places in `sage` so the
idiom is established and will be familar to people. Rather than the
category being "behind the scenes", I think that the element category is
an integral part of specifying the algebra so it should be part of
algebra's class - having to call a random external class for the category,
and further poluting sage's namespace, just seems wrong to me.
>
> If you want to rename the class something other than `Bases` I certainly
won't object as I agree that the name is misleading. Still, I vote for
keeping the category class internal to `IwahoriHeckeAlegbra` as it
currently is.
It is only used in `QSym` and `NCSF` as far as I known, and they are tied
together. In particular, it is not used for symmetric functions. However I
was not importing it into the global namespace, but instead it was just in
the module's namespace. How about a middle ground of calling it
`_BasesCategory` or something else where it is private?
Best,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:55>
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.
