d06b82bc-eb37-48a6-9e6a-dbbee712c170
commented
11 years ago Attachment: trac_14261_iwahori_hecke.patch.gz
Closed d06b82bc-eb37-48a6-9e6a-dbbee712c170 closed 10 years ago
d06b82bc-eb37-48a6-9e6a-dbbee712c170
commented
11 years ago Attachment: trac_14261_iwahori_hecke.patch.gz
tscrim
commented
11 years ago Hey Brant,
I've uploaded a new version of the patch which reworks the implementation to follow the WithRealizations API and deprecates the IwahoriHeckeAlgebraT class. If it wasn't ready for review, I think it now is.
Best,
Travis
tscrim
commented
11 years ago Changed author from Brant Jones to Brant Jones, Travis Scrimshaw
tscrim
commented
11 years ago I should also state that I had to upload a new version of the patch because Brant's patch did not apply on 5.9 due to the changes in the doc. Also for got this.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch
tscrim
commented
11 years ago Description changed:
---
+++
@@ -4,3 +4,9 @@
See http://wiki.sagemath.org/HeckeAlgebras for some design discussion.
+---
+
+Apply:
+
+* [attachment: trac_14261-iwahori_hecke-ts.patch](https://github.com/sagemath/sage-prod/files/10657354/trac_14261-iwahori_hecke-ts.patch.gz)
+New version which also adds bar involution on the T_basis and some tweaks to the documentation.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch
AndrewMathas
commented
11 years ago A few comments:
I think that it is a little dangerous implementing the Kazhdan-Lusztig C'-basis and calling it the C-basis. The documentation says clearly that this is the C'-basis but these names have been in use for 30+ years at this point so I think at the minimum you need to warn people about this. (This is even though I agree that KL got the names of these two bases "wrong":)
As the code is essentially the same, it would be good to implement both KL C-basis and the KL C'-basis. This would solve the problem above but it also runs into the issue of what to call the C'-basis. Perhaps use C_basis and Cp_basis?
Having just said that the code is 'the same' in terms of caching it would be better to implement the C'-basis using the observation that C_x' = \alpha(C_x), where \alpha is the Z-linear ring automorphism of the Hecke algebra which sends q^1/2} ^to -q-1/2 and Tx to (-1)\ell(x)q-1/2\ell(x)Tx.
tscrim
commented
11 years ago So which would you call the KL basis, C or C' (I believe calling [one of these] the KL is fairly standard)? I think the best name should be C_prime_basis since it is explicit, but we can have Cp and C_prime as shortcuts.
I'll also implement the ring automorphism \alpha and implement the C basis in the next version. Thanks for looking at this Andrew.
nthiery
commented
11 years ago It's probably not necessary to put the _basis suffix. Elsewhere, we use Sym.s, Sym.p and so on and not Sym.s_basis.
Cheers, Nicolas
tscrim
commented
11 years ago New version which implements both the C and C' bases, removed the _basis suffix, and implements the Hecke involution Andrew described above as hecke_involution() to elements in the T basis. I choose the call the C' basis the Kazhdan-Lusztig since this is the bar invariant basis. However going between the C and T currently has a problem which I'm trying to work out; in particular, I believe the T -> C is wrong but the C -> T is correct.
tscrim
commented
11 years ago Work Issues: T <-> C basis map
tscrim
commented
11 years ago I fixed the problem and added some more doctests and added hecke_involution() and bar() to elements in the C and C' bases. Ready for review again.
tscrim
commented
11 years ago Changed work issues from T <-> C basis map to none
tscrim
commented
11 years ago This might need rebasing over #14014 since I believe that changes the order of the elements in the Weyl group which might affect the output order of our expressions. Also it seems like #14014 is almost done.
tscrim
commented
11 years ago Dependencies: #14014
tscrim
commented
11 years ago Rebased over #14014.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch
tscrim
commented
11 years ago Changed dependencies from #14014 to #13735 #14014
tscrim
commented
11 years ago Also rebased over #13735.
tscrim
commented
11 years ago Rebased over #14678 (trivial: some fuzz).
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch
tscrim
commented
11 years ago Changed dependencies from #13735 #14014 to #13735 #14014 #14678
nthiery
commented
11 years ago Hi!
I got a time out yesterday while running all long tests. It's likely that the associativity tests in the TestSuite are pretty expensive; maybe those should be skipped and run separately on some explicitly passed elements; something like:
sage: TestSuite(C).run(skip=["_test_associativity"])
sage: C._test_associativity(elements=[...])They (also distributivity and prod) took so long because the an_element() was quite big. I factored it out.
Apply: trac_14261-iwahori_hecke-ts.patch
tscrim
commented
11 years ago Change in index_set() due to #14516.
Apply: trac_14261-iwahori_hecke-ts.patch
tscrim
commented
11 years ago Changed dependencies from #13735 #14014 #14678 to #13735 #14014 #14678 #14516
darijgr
commented
11 years ago not a review
darijgr
commented
11 years ago Attachment: trac_14261_a_few_fixes_dg.patch.gz
I've just looked into the patch to see how algebras with multiple bases are implemented; I don't really know (or care much, by now) about Hecke algebras. I've uploaded a few superficial docstring fixes.
An issue I'm not fixing but you might want to ponder about are the docstrings of bar(self) and hecke_involution(self). They pretend that these methods send the deformation variable q to q^(-1) (or q^(1/2) to q^(-1/2), which is more or less the same). But what they actually invert is not the deformation variable, but rather the indeterminates generating the Laurent polynomial ring in which the deformation variable resides. So if the deformation variable is, say, 2t, then t is sent to t^(-1), not 2t to (2t)^(-1). I don't know in how far this issue will pop up in real life, but here's an example:
sage: W.<t> = LaurentPolynomialRing(QQ)
sage: H = IwahoriHeckeAlgebra(['A',3], 2*t)
sage: T = H.T()
sage: T1,T2,T3 = T.algebra_generators()
sage: T1.bar()
(1/2*t^-1)*T1 + (-1+1/2*t^-1)
sage: (t*T1).bar()
(1/2*t^-2)*T1 + (-t^-1+1/2*t^-2)Hey Darij,
Thanks for looking over the documentation. As for the q, in order to do what you're suggesting means we have to do all computations in a formal variable and then specialize. However I don't think this is the correct behavior, especially when q is a root of unity, but I don't know if the bar involution is still useful at specialized q. The problem in my mind is take q = 2 and consider the element 2, what is the bar of this, does it matter if it's 1 + 1 or 2 in ZZ or suppose to be the q?
Andrew, Dan, Brant, or someone who understands Hecke algebras better than myself, do you have any thoughts on this? Also would any of you have time to do the last (math) review of this patch?
Best,
Travis
darijgr
commented
11 years ago Hi Travis,
You're right, the only thing we can do with 2 is leave it fixed. So the implementation is right and the docstring is wrong: the only thing we can do is invert the indeterminates; inverting the deformation parameter doesn't in general work.
Best regards,
Darij
tscrim
commented
11 years ago Here's the new version of the patch with the review patch folded in which fixes errors in the basis conversions and reworks the code using the bases category to avoid some redundancy.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch
AndrewMathas
commented
11 years ago Given the issues that we're having in computing the KL bases I think that we need some basic tests like:
sage: T(Cp(1))
v^-1*Cp1 + v^-1
sage: T(C(1))
v^-1*Cp1 - v
sage: C(Cp(1))
C1 + (v+v^-1)
sage: Cp(C(1))
Cp1 + (-v-v^-1)I think that there also should be long tests like:
sage: forall( C(x)==C(T(x)) for x in W )
true
sage: forall( C(x)==C(Cp(x)) for x in W )
true
sage: forall( Cp(x)==Cp(T(x)) for x in W )
true
sage: forall( Cp(x)==Cp(C(x)) for x in W )
truewhere W is at least Sym(4) or of type B2 or ...
As there is an independent implementation of the KL-polys inside sage (I think???) it should also be possible to do something like:
sage: T(Cp(x)) == v^-x.length()*sum( KLPoly(y,x)*T(y) for y in W)Apologies but I don't know the right syntax here.
AndrewMathas
commented
11 years ago Replying to @tscrim:
Hey Darij,
Thanks for looking over the documentation. As for the
q, in order to do what you're suggesting means we have to do all computations in a formal variable and then specialize. However I don't think this is the correct behavior, especially whenqis a root of unity, but I don't know if the bar involution is still useful at specializedq. The problem in my mind is takeq = 2and consider the element2, what is the bar of this, does it matter if it's1 + 1or2 in ZZor suppose to be theq?Andrew, Dan, Brant, or someone who understands Hecke algebras better than myself, do you have any thoughts on this? Also would any of you have time to do the last (math) review of this patch?
Best,
Travis
The correct way of doing this is to work with an indeterminant/formal variable to compute the KL-basis elements and then specialise. The bar involution really only makes sense when q is generic.
Andrew
anneschilling
commented
11 years ago Once you install coxeter3 with
sage -i http://sage.math.washington.edu/home/nthiery/coxeter3-1.1.spkgyou can get KL polynomials via
sage: from sage.libs.coxeter3.coxeter import get_CoxGroup as CoxGroup
sage: W = CoxGroup(['A',2])
sage: W([]).kazhdan_lusztig_polynomial([1,2,1])Anne
AndrewMathas
commented
11 years ago ..and I guess there should also be some tests
sage: forall( C(x)==C(x).bar() for x in W)
true
sage: forall( Cp(x)==Cp(x).bar() for x in W)
trueI know I talked with Nicolas about this earlier, and he disagreed, but I think that the current syntax is not ideal. I'd rather have something like:
sage: H.C(1)
C1
sage: H.T(H.Cp(1))
v^-1T1+v^-1The current extra layer of bracketting, together with the special use of [] verus () for indexes and algebra elements, I find counterintuititive. By making H.C() etc a hook to the actual basis class it maybe possible to do better than the current syntax?
(Btw, I tried using H.inject_shorhands() but this just gave an error message.)
The syntax for defining the Hecke algebra itself also strikes me as being a little OTT:
sage: H = IwahoriHeckeAlgebra(['A',3], v^2, -1, v, 1)Is there a way of simplifying this? For example, from memory chevie computes the KL bases internally using an indeterminant and then specialised back to the square root of the Hecke parameter.
AndrewMathas
commented
11 years ago Changed reviewer from Andrew Mathas?, Dan Bump? to Andrew Mathas, Dan Bump?
tscrim
commented
11 years ago Okay here's the version which has the correct bases, but I'm not getting the correct KL polynomials. The question becomes is this correct and KL polynomials in Sage and Coxeter3 wrong or vice versa. Hand computations are needed.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch
tscrim
commented
11 years ago Work Issues: KL polynomials
anneschilling
commented
11 years ago Replying to @tscrim:
Okay here's the version which has the correct bases, but I'm not getting the correct KL polynomials. The question becomes is this correct and KL polynomials in Sage and Coxeter3 wrong or vice versa. Hand computations are needed.
Sage has two KL polynomial implementations. The other one is by Dan Bump:
sage: W = WeylGroup("B3",prefix="s")
sage: [s1,s2,s3]=W.simple_reflections()
sage: R.<q>=LaurentPolynomialRing(QQ)
sage: KL=KazhdanLusztigPolynomial(W,q)
sage: KL.P(s2,s3*s2*s3*s1*s2)
q + 1It is unlikely that both are wrong!
Anne
tscrim
commented
11 years ago I'm also suspecting it's something with the code, but everything seems to be working code-wise...I'm going to run some more tests too.
Here's a second patch which changes the interface so that you can just input q1 and sqrt_q1 without having to worry about q2:
sage: R.<v> = LaurentPolynomialRing(QQ)
sage: H = IwahoriHeckeAlgebra(['A',3], v^2, v)For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch, trac_14261-alt_interface-ts.patch
AndrewMathas
commented
11 years ago Replying to @anneschilling:
Replying to @tscrim :
Okay here's the version which has the correct bases, but I'm not getting the correct KL polynomials. The question becomes is this correct and KL polynomials in Sage and Coxeter3 wrong or vice versa. Hand computations are needed.
Sage has two KL polynomial implementations. The other one is by Dan Bump:
sage: W = WeylGroup ("B3",prefix="s") sage: [s1,s2,s3]=W.simple_reflections() sage: R.<q>=LaurentPolynomialRing (QQ) sage: KL=KazhdanLusztigPolynomial (W,q) sage: KL.P(s2,s3*s2*s3*s1*s2) q + 1It is unlikely that both are wrong! Anne
Hi Travis and Anne,
This is the first interesting KL-polynomial and the polynomial is 1+q=1+v^2. So the result being returned by the basis code is correct and the result being returned by the KL.poly sum is wrong. The problem is that KL.P is returning a polynomial in v whereas in the sum we want a polynomial in v^2. So all that needs to be done to fix this is make KL.P return a polynomial in v^2.
Andrew
tscrim
commented
11 years ago And there's option C: I'm being an idiot. Thank you Andrew. Here's the patch with the corrected docstrings (and most of the all tests marked as # long time).
Next question, is anyone against my proposed interface? I don't think I can manage to get C(1) to return the same as C[1] due to the coercion model. IMO, I don't see this as confusing since the syntax is different, and since there is different syntax, we are okay with different output.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch, trac_14261-alt_interface-ts.patch
tscrim
commented
11 years ago Attachment: trac_14261-alt_interface-ts.patch.gz
tscrim
commented
11 years ago Changed reviewer from Andrew Mathas, Dan Bump? to Andrew Mathas, Brant Jones, Travis Scrimshaw
tscrim
commented
11 years ago Here are the new versions of the patches with the changes Brant and I discussed via e-mail which changes the output of the C and Cp bases.
For patchbot:
Apply: trac_14261-iwahori_hecke-ts.patch, trac_14261-alt_interface-ts.patch
tscrim
commented
11 years ago Changed work issues from KL polynomials to none
AndrewMathas
commented
11 years ago I'm part way through writing a review patch. Mostly I have just been expanding on the documentation (and hopefully improving it). In particular, I have added Iwahori-Hecke algebras to the algebra chapter of the reference manual, as it didn't seem to exist anywhere else.
There is one significant issue that needs to be addressed: currently the code accepts two parameters q1 and q2 and defines the algebra with generators {T_s|s\in S} and relations (T_s-q1)(T_s-q2)=0 together with the braid relations. I am unsure how to define the bar involution for such parameters.
What the code currently does is invert all of the generators of the base ring. This is probably the right thing to do if q1 and q2 are powers of generators of the base ring -- although even this is not clear because we could have q1=v^2 and but be working with the Hecke algebra over Z[v,w], so that we would probably want \bar[w}=w. Of course, I can't image why one would ever want to do this...
A less extreme (and more natural), example is when q1=a^2, q2=b^2 and a and b are not algebraically independent. In this case, this bar involuton on the base ring will almost never extend to a ring involution on te Hecke algebra.
What is cool about the current implementation is that it works correctly with parameters (q1,q2) being either (v^2,-1) or (v,-v^-1). What is less cool is that it will be wrong in the senarious above and, more seriously, it gives incorrect answers when given parameters (1,-1) which corresponds to the group ring ZW:
sage: H = IwahoriHeckeAlgebra(['A',3], 1,1)
sage: H.inject_shorthands()
Injecting C as shorthand for Iwahori-Hecke algebra of type A3 in 1,-1 over Integer Ring in the C basis
Injecting Cp as shorthand for Iwahori-Hecke algebra of type A3 in 1,-1 over Integer Ring in the Kazhdan-Lusztig basis
Injecting T as shorthand for Iwahori-Hecke algebra of type A3 in 1,-1 over Integer Ring in the standard basis
sage: T(Cp(1))
1The underlying problem is that the bar involution really only makes sense in the generic case and currently there is no checking for this. On the other hand, the Kazhdan-Lusztig bases do make sense whenever the squre root of the prameters lives in the base ring as we can compute the KL bases over Z[v,v^-1] and then specialise v^2 to q. In particular, the KL bases make sense for the integral groups rings ZW.
I can think of a couple of solutions:
I don't like the first option because the current behaviour is mathematically incorrect in important examples. Nor do I like the second option because working with the KL bases of the group algebra is a natural thing to want to do. Therefore, I think that the last option is the way to go.
Please let me know what you think.
Here are a few other less important issues that I have come across:
one_basis method of all of the bases: why does this return the identity element of the corresponding Coxeter group? Initially I thought that this would return the identity element of the Hecke algebra with respet to the current basis (which is implemented asT.one()). If we really need a shorthand for the identity element of the group shouldn't the method be called something like group_identity?is_field strikes me as being strange: the Hecke algebra is a field if only if the Coxeter group has rank zero and the base ring is a field. Rather than being a method of the Hecke algebra this should be (and is) a method of the base ring of the Hecke algebra. Iwahori-Hecke algebra of type A3 in v^2,-1 over Univariate Laurent Polynomial Ring in v over Rational Field in the C basis
Iwahori-Hecke algebra of type A3 in v^2,-1 over Univariate Laurent Polynomial Ring in v over Rational Field in the Kazhdan-Lusztig basis
Iwahori-Hecke algebra of type A3 in v^2,-1 over Univariate Laurent Polynomial Ring in v over Rational Field in the standard basisUnless anyone objects, in my review patch I will remove the is_field method, rename (or delete?) the one_basis method and shorten the basis names.
In the bsence of better suggesstions I will also have a go at implementing a generic algebra in the background.
tscrim
commented
11 years ago Thank you for reviewing this ticket Andrew.
Replying to @AndrewAtLarge:
I'm part way through writing a review patch. Mostly I have just been expanding on the documentation (and hopefully improving it). In particular, I have added Iwahori-Hecke algebras to the algebra chapter of the reference manual, as it didn't seem to exist anywhere else.
Yes, this should be done.
There is one significant issue that needs to be addressed: currently the code accepts two parameters
q1andq2and defines the algebra with generators{T_s|s\in S}and relations(T_s-q1)(T_s-q2)=0together with the braid relations. I am unsure how to define the bar involution for such parameters....
The underlying problem is that the bar involution really only makes sense in the generic case and currently there is no checking for this. On the other hand, the Kazhdan-Lusztig bases do make sense whenever the squre root of the prameters lives in the base ring as we can compute the KL bases over
Z[v,v^-1]and then specialisev^2toq. In particular, the KL bases make sense for the integral groups ringsZW.I can think of a couple of solutions:
- Leave everything as it is.
- Only allow the KL bases to be implemenetd in the generic case.
- Implement a generic Hecke algebra behind the scene and compute the KL basis here, together with transition matrices, and then specialise these results into the non-generic Hecke algebras whenever the square roots of the parameters are (testably) well-defined.
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.
Here are a few other less important issues that I have come across:
- I am confused by the
one_basismethod of all of the bases: why does this return the identity element of the corresponding Coxeter group? Initially I thought that this would return the identity element of the Hecke algebra with respet to the current basis (which is implemented asT.one()). If we really need a shorthand for the identity element of the group shouldn't the method be called something like group_identity?
This is correct; 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).
- Similarly, the method
is_fieldstrikes me as being strange: the Hecke algebra is a field if only if the Coxeter group has rank zero and the base ring is a field. Rather than being a method of the Hecke algebra this should be (and is) a method of the base ring of the Hecke algebra.
I'm not really opposed to removing it, but I'm thinking it should be in there for consistency (with perhaps modified behavior).
- I think that the names for the bases are all too long to be useful and that something shorter like "X-basis of Iwahori-Hecke algebra" or "X-basis of Iwahori-Hecke algebra of type Y" feasible? Compare these with:
Iwahori-Hecke algebra of type A3 in v^2,-1 over Univariate Laurent Polynomial Ring in v over Rational Field in the C basis Iwahori-Hecke algebra of type A3 in v^2,-1 over Univariate Laurent Polynomial Ring in v over Rational Field in the Kazhdan-Lusztig basis Iwahori-Hecke algebra of type A3 in v^2,-1 over Univariate Laurent Polynomial Ring in v over Rational Field in the standard basis
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.
AndrewMathas
commented
11 years ago Replying to @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<sup>{1/2},q</sup>{-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 forCombinatorialFreeModule(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 Fieldpart) since it helps distinguish the Hecke algebras. Thein the X basispart is a standard paradigm from otherWithRealizationobjects 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!
tscrim
commented
11 years ago Replying to @AndrewAtLarge:
Replying to @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<sup>{1/2},q</sup>{-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
RWof the Coxeter group has a well-defined KL basis for any ringR, however, you can't "see" the KL bases ofRWinside the group ring. The only way to compute the KL bases orRWis to do it inside the generic Hecke algebra and then specialise. Notice also that even though the KL bases are defined forRWthe bar involution is NOT defined onRW, 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 forCombinatorialFreeModule(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_basisis used as a shortcut to get to things likeT(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_fielda 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 Fieldpart) since it helps distinguish the Hecke algebras. Thein the X basispart is a standard paradigm from otherWithRealizationobjects 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.
nthiery
commented
11 years ago Replying to @AndrewAtLarge:
Here are a few other less important issues that I have come across:
- I am confused by the
one_basismethod of all of the bases: why does this return the identity element of the corresponding Coxeter group? Initially I thought that this would return the identity element of the Hecke algebra with respet to the current basis (which is implemented asT.one()). If we really need a shorthand for the identity element of the group shouldn't the method be called something like group_identity?
From the documentation of one_basis in AlgebrasWithBasis (now in Algebras.Unital.WithBasis.ParentMethods.one_basis):
When the one of an algebra with basis is an element of
this basis, this optional method can return the index of
this element. This is used to provide a default
implementation of :meth:`.one`, and an optimized default
implementation of :meth:`.from_base_ring`.
So just a little standard shortcut which furthermore gives the system a bit of information that can be used for some optimizations.
Set up the algebra to handle multiple bases; implemented the Kazhdan--Lusztig basis.
This is a follow up to ticket #7729.
See http://wiki.sagemath.org/HeckeAlgebras for some design discussion.
Apply:
Depends on #13735 Depends on #14014 Depends on #14678 Depends on #14516 Depends on #15257
CC: @sagetrac-sage-combinat @anneschilling @AndrewAtLarge @samclearman @zabrocki
Component: combinatorics
Keywords: Iwahori Hecke algebra, days45
Author: Brant Jones, Travis Scrimshaw, Andrew Mathas
Reviewer: Andrew Mathas, Brant Jones, Travis Scrimshaw
Merged: sage-5.13.beta1
Issue created by migration from https://trac.sagemath.org/ticket/14261