#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 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'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.

 > 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)`.

 > 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!:)

 > 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.

 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!

--
Ticket URL: <http://trac.sagemath.org/ticket/14261#comment:36>
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.

Reply via email to