#14261: Iwahori-Hecke algebra with several bases
-------------------------------------+-------------------------------------
Reporter: brant | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Keywords: Iwahori Hecke | Merged in:
algebra | Reviewers: Andrew Mathas, Brant
Authors: Brant Jones, | Jones, Travis Scrimshaw
Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: #13735 #14014 |
#14678 #14516 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:36 andrew.mathas]:
> Replying to [comment:35 tscrim]:
>
> > Thank you for reviewing this ticket Andrew.
>
> Well, I haven't actually finished a review yet! Thanks for getting back
to me.
I note the tense of the verb :P
> > I'm slightly hesitant about option 3 (implementing a generic Hecke
algebra), and it's probably due to my lack of expertise, but does it
always work for specializing to roots of unity? Or do problems just arise
with the representation theory? If it's okay, then I'm for option 3.
Actually, that made me have another (scarier) thought, does anyone know if
this works for fields of positive characteristic? If not or we don't know,
I think we should put that in the documentation somewhere that we assume
the base ring has characteristic 0.
>
> The KL bases are defined over `Z[q^{1/2},q^{-1/2}]` so you can
specialise them to ANY ring provided these square roost exist. You can't,
however, compute these bases over any ring becaue the bar involution will
not be defined in general. Therefore, one really SHOULD compute them
generically and then specialise.
>
> To be explicit, the group ring `RW` of the Coxeter group has a well-
defined KL basis for any ring `R`, however, you can't "see" the KL bases
of `RW` inside the group ring. The only way to compute the KL bases or
`RW` is to do it inside the generic Hecke algebra and then specialise.
Notice also that even though the KL bases are defined for `RW` the bar
involution is NOT defined on `RW`, so non-generic Hecke algebras should
not have a method for the bar involution either.
>
> The KL bases also work in the root of unity cases...it is more that no
one has found a good use for them yet.
Then I'm for it. I'm guessing we only would want the generic structure for
the basis transitions and let the bar and Hecke involution methods fail as
necessary (with proper documentation of course). I'd imagine that we
shouldn't see too big (if any) of a speed penality doing it this way.
> > This is correct [about `one_basis`]; it is suppose to return the index
of basis element for the Hecke's algebra's (multiplicative) identity. It's
something needed for `CombinatorialFreeModule` (at least, I'm pretty
sure).
>
> I don't believe this. Combinaorial modules can be indexed anything so it
seems unlikely that they would require something in the index set to be a
multiplicative identity. In the code `one_basis` is used as a shortcut to
get to things like `T(1)`.
It's useful in the `to_*_basis()` methods because their argument is given
in terms of an indexing element. Only at one place in the code did
`T(T.one_basis())` get used and could be turned into `T.one()`. If you're
still thinking of changing this to `one()` (which you do need to implement
otherwise), then we'll see if something else breaks (and you might
consider asking Nicolas about it).
> > I'm not really opposed to removing it, but I'm thinking it should be
in there for consistency (with perhaps modified behavior).
>
> Is `is_field` a default method for an algebra? Most algebras are not
fields so this struck me as being a strange question to ask
mathematically. If you accept this then you should agree that it is a
strange method for an algebra. (But perhaps it is just me who is
strange!:)
Since the class `Algebra` inherits from `Ring`, it does have this method.
However the category `Rings`, which is a super-category of (unital,
associative) `Algebras`, does not have an `is_field` method (I think
because you're suppose to test it like `R in Fields()`, but don't quote me
on that), so it's okay to remove it.
Now down the rabbit hole: as to it being strange, I don't have the
experience to say. I do agree that most algebras are not fields, but then
again, so are most rings. However isn't the fraction field of an algebra
also an algebra?
> > I don't like removing the base ring in the representation (the
`Univariate Laurent Polynomial Ring in v over Rational Field` part) since
it helps distinguish the Hecke algebras. The `in the X basis` part is a
standard paradigm from other `WithRealization` objects such as symmetric
functions.
>
> I agree that this could be useful but I always err on the side of
readabiltly and ease of use.
IMO the string representations of parents are mainly used to remind us
what they are or to identify them. Leaving off the base ring makes it
harder to achieve this. If you're still wanting more readability, perhaps
a global option is in order with the default being the more descriptive
string (although we might need to be careful about the hash...)?
> I will try and incorporate some or all of the above into the review
patch and get it back to you tomorrow (possibly optimistic). Going via the
generic algebra turns out to be a minor rearrangement of code (I think),
so it shoudn't be too hard - I hope!
I don't think it should be difficult. Thank you Andrew.
--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:37>
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.
