Infinite affine crystals should use extended weight lattice

6bbcde06-8197-41f1-b9a3-c998bb839000 commented 9 years ago

Infinite affine crystals should use the extended weight lattice. This would include both B(infinity) crystals and crystals of integrable representations.

Here is an example.

sage: C = crystals.infinity.NakajimaMonomials(['A',1,1])
sage: v=C.highest_weight_vector()
sage: v.f(1).weight()+v.f(0).weight()
0

The answer should be -delta. The problem is that the extended weight lattice is not being used.

CC: @sagetrac-sage-combinat @bsalisbury1 @tscrim @anneschilling @nthiery @sagetrac-ptingley

Component: combinatorics

Keywords: crystals, days65

Author: Ben Salisbury, Anne Schilling, Travis Scrimshaw

Branch: ee398ef

Reviewer: Dan Bump

Issue created by migration from https://trac.sagemath.org/ticket/18453

tscrim commented 9 years ago

Changed keywords from none to crystals

tscrim commented 9 years ago

comment:3

My proposal is to change the default value for the weight lattice to be the extended version by default since it would have the proper dimension and is the more natural thing to do weight computations in. As a result, we should create a new category for U_q'(g)-crystals which uses the non-extended weight lattice. This would give us:

greater flexibility long-term to implement generic methods for things like energy, R-matrices, and perfectness,
better support once I patch up morphisms (#15463), and
allow us to fix a (IMO) hack in the default plotting options of 0 arrows of not reversing them by checking if a crystal is not in the category of highest weight crystals.

At least to fix this ticket, I don't think there would be much work. However it would be a backwards-incompatible change; although I think it would be mild.

6bbcde06-8197-41f1-b9a3-c998bb839000 commented 9 years ago

comment:4

There may be cases where one does not want the extended weight lattice. For example Kirillov-Reshetikhin crystals, I think it would complicate things if you used the extended weight lattice.

This is addressed by Travis' proposal since he would create a new category for finite crystals that use the non-extended weight lattice.

The alternative way of fixing things would be to find the places where the wrong weight lattice is created (for example in the !__classcall_private!__ method o InfinityCrystalOfNakajimaMonomials and add extended=True to the parameters of weight_lattice. Both ways would fix the problem.

One question is whether we more often than not want affine weight lattices to be extended. I myself do. So I would support Travis' proposal but I am pointing out that there is an alternative.

tscrim commented 9 years ago

Commit: b4a7647

tscrim commented 9 years ago

Author: Travis Scrimshaw

tscrim commented 9 years ago

Branch: public/combinat/fix_crystal_weight_lattice-18453

tscrim commented 9 years ago

comment:5

Okay, here's a rough draft of my proposal that mostly works. I would like some feedback, in particular from Nicolas on the change of the behavior and the reorganization of the code. There also seems to be a subtle issue with subclassing and @cached_method (with my branch):

sage: P = RootSystem(['A',3,1]).weight_lattice()
sage: P.fundamental_weight('delta')
delta
sage: P.fundamental_weights()
Finite family {0: Lambda[0], 1: Lambda[1], 2: Lambda[2], 3: Lambda[3]}

Restart Sage and do

sage: P = RootSystem(['A',3,1]).weight_lattice()
sage: P.fundamental_weights()
Finite family {0: Lambda[0], 1: Lambda[1], 2: Lambda[2], 3: Lambda[3]}
sage: P.fundamental_weight('delta') # This is now the method of the base class!!!
...
ValueError: delta is not in the index set

I have no idea about why this occurs, much less how to fix this.

However it does not actually fix the problem noted on this ticket as we compute the weight by Phi - Epsilon. I've fixed this directly for LS paths (to which we need to be much more careful with the category) and rigged configurations. For Nakajima monomials, I'm not quite sure how to fix it. I really don't want to special case the affine types. In Kang et al., they construct B(\infty) by the path realization, and so I think they consider it as a U'_q(g)-crystal (and so is in the non-extended weight lattice).

(Additionally, the weight function isn't correct for the Kyoto path model either, but that is a separate issue.)

New commits:

`7663e78`	`Implement category of KR crystals and reorganizing (extended) weight spaces.`
`6e0ba04`	`Fixing my errors from the conversion.`
`b4a7647`	`Fixing weight for LS paths and rigged configurations.`

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from b4a7647 to cbd6e19

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

cbd6e19 Merge branch 'develop' into public/combinat/fix_crystal_weight_lattice-18453

anneschilling commented 9 years ago

New commits:

`2dc88c1`	`18453: first changes to LS paths`
`0ba39d0`	`18453: added doctests`
`901a865`	`18543: fixed Weyl dimension formula`

anneschilling commented 9 years ago

Changed branch from public/combinat/fix_crystal_weight_lattice-18453 to public/crystal/18453

anneschilling commented 9 years ago

Changed commit from cbd6e19 to 901a865

anneschilling commented 9 years ago

comment:8

Ben and I are going to fix this in a different way. I had to fix the Weyl dimension formula (which I guess was written by Nicolas and only worked in the ambient space). So please check. Ben will add fixes to the other crystals, but the Littlemann paths should be fixed now.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from 901a865 to 45ca9ee

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

`6a225ee`	`Preliminary changes to GYW weight code.`
`ef4867d`	`Merge branch 'public/crystal/18453' of git://trac.sagemath.org/sage into 18453`
`5f42e6d`	`more changes to GYWs`
`45ca9ee`	`finished GYW updates`

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from 45ca9ee to 9225af7

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

9225af7 18543: small typo fixed in generalized_young_walls

anneschilling commented 9 years ago

Changed author from Travis Scrimshaw to Ben Salisbury, Anne Schilling, Travis Scrimshaw

anneschilling commented 9 years ago

New commits:

`6a225ee`	`Preliminary changes to GYW weight code.`
`ef4867d`	`Merge branch 'public/crystal/18453' of git://trac.sagemath.org/sage into 18453`
`5f42e6d`	`more changes to GYWs`
`45ca9ee`	`finished GYW updates`
`9225af7`	`18543: small typo fixed in generalized_young_walls`

anneschilling commented 9 years ago

comment:12

Hi Travis,

littelmann_paths and generalized_young_walls are fixed. Ben is working on monomials to get the hyperbolic cases working. Could you fix the rigged configuration crystals by implementing the correct weight and weight_lattice_realization? In this ticket we do not want to revamp all the root_system stuff that you added in your previous patch and the category changes for KR crystals.

Thanks!

Anne

tscrim commented 9 years ago

comment:13

I'm pretty sure this will not end up fixing most of the problems and it feels like we're hacking around the problem. At the very least as a better patch, I think we could solve a host of issues by just checking if the type is affine and if the crystal is not in finite crystals to pass extended=True. However I will fix the RC code and test a bunch of the different models in affine type as soon as I'm able to today.

tscrim commented 9 years ago

comment:14

I've fixed the rigged configurations

CrystalOfAlcovePaths fails outright:

sage: C = crystals.AlcovePaths(La[0])
sage: C
Highest weight crystal of alcove paths of type ['A', 1, 1] and weight Lambda[0]
sage: C.module_generators[0].f_string([0,1])
((alpha[0], 0), (2*alpha[0] + alpha[1], 1))
sage: _.weight()
TypeError

We should also explicitly implement a weight_lattice_realization for DirectSumOfCrystals similar to what we did for tensor products.
We have to decide what we want to do with KyotoPathModel and if we want to consider it as a U_q'-crystal or a U_q-crystal. I think the former is what we should do considering it is a tensor product of U_q'-crystals. In any case, we will probably have to do something special for this.
We have a problem with not distinguishing between elements of the extended and non-extended affine weight lattices. In particular, this causes an issue with creating the highest weight crystals with the same weight but you accidentally first create it in the non-extended affine weight lattice.

sage: LaE = RootSystem(['A',2,1]).weight_space(extended=True).fundamental_weights()sage: La = RootSystem(['A',2,1]).weight_space().fundamental_weights()
sage: B = crystals.LSPaths(La[0])
sage: B2 = crystals.LSPaths(LaE[0])
sage: B is B2
True

I had changed crystals.RiggedConfigurations with inadvertantly triggered this. I don't think we want to enforce that the user must consider weights in the extended affine weight lattice as it is a valid restriction from U_q to U_q' (in particular, the Kyoto path model). IMO the solution would be for __classcall__/__classcall_private__ to pass the weight lattice realization with the default to use the parent of the weight given. I feel this gives the user added flexibility for where they want the weights to be printed. Although part of me also thinks there should be some kind of option which could be changed in the method-input/classes/globally which specifies the weight lattice realization.

I will be on skype all day today if you want to talk.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from 9225af7 to 7963ea6

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

7963ea6 Fixing WLR for rigged configurations.

nthiery commented 9 years ago

comment:16

Replying to @tscrim:

However I will fix the RC code and test a bunch of the different models in affine type

Just random thoughts: will failure be caught by TestSuite? If not could there be new _test methods catching the issue?

nthiery commented 9 years ago

comment:17

Replying to @anneschilling:

I had to fix the Weyl dimension formula (which I guess was written by Nicolas and only worked in the ambient space).

By Dan, if I recall correctly.

tscrim commented 9 years ago

comment:18

Replying to @nthiery:

Replying to @tscrim:

However I will fix the RC code and test a bunch of the different models in affine type

Just random thoughts: will failure be caught by TestSuite? If not could there be new _test methods catching the issue?

I don't think we could write a TestSuite check for this (at least for the highest weight crystals) as the branching rule I mentioned above is valid (and so having the weights in the non-extended weight lattice still makes sense, unless I'm misunderstanding something about U_q'(g) inside of U_q(g)).

anneschilling commented 9 years ago

comment:19

Replying to @nthiery:

Replying to @anneschilling:

I had to fix the Weyl dimension formula (which I guess was written by Nicolas and only worked in the ambient space).

By Dan, if I recall correctly.

7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  859)         def weyl_dimension(self, highest_weight):
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  860)             """
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  861)             EXAMPLES::
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  862) 
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  863)                 sage: RootSystem(['A',3]).ambient_lattice().weyl_dimension([2,1,0,0])
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  864)                 20
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  865) 
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  866)                 sage: type(RootSystem(['A',3]).ambient_lattice().weyl_dimension([2,1,0,0]))
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  867)                 <type 'sage.rings.integer.Integer'>
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  868)             """
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  869)             highest_weight = self(highest_weight)
f562ca2b (Travis Scrimshaw  2014-10-01 17:16:31 -0700  870)             if not highest_weight.is_dominant():
f562ca2b (Travis Scrimshaw  2014-10-01 17:16:31 -0700  871)                 raise ValueError("the highest weight must be dominant")
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  872)             rho = self.rho()
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  873)             n = prod([(rho+highest_weight).dot_product(x) for x in self.positive_roots()])
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  874)             d = prod([ rho.dot_product(x) for x in self.positive_roots()])
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  875)             from sage.rings.integer import Integer
7d693534 (Nicolas M. Thiery 2012-03-19 21:38:26 +0100  876)             return Integer(n/d)

But in any case, someone should check!

anneschilling commented 9 years ago

comment:20

CrystalOfAlcovePaths fails outright:

sage: C = crystals.AlcovePaths(La[0])
sage: C
Highest weight crystal of alcove paths of type ['A', 1, 1] and weight Lambda[0]
sage: C.module_generators[0].f_string([0,1])
((alpha[0], 0), (2*alpha[0] + alpha[1], 1))
sage: _.weight()
TypeError

No, it does not. You did not send how you made the weight La. I assume you used the weight_lattice and not weight_space (which you have to for this model!!)

sage: R = RootSystem(['A',1,1])
sage: P = R.weight_space()
sage: La = P.basis()
sage: C = crystals.AlcovePaths(La[0])
sage: b = C.module_generators[0].f(0)
sage: b
((alpha[0], 0),)
sage: b.weight()
-Lambda[0] + 2*Lambda[1]

We should also explicitly implement a weight_lattice_realization for DirectSumOfCrystals similar to what we did for tensor products.

We have to decide what we want to do with KyotoPathModel and if we want to consider it as a U_q'-crystal or a U_q-crystal. I think the former is what we should do considering it is a tensor product of U_q'-crystals. In any case, we will probably have to do something special for this.

Mathematically speaking, the Kyoto path model is a model in the category of highest weight affine crystals. It is a U_q(g)-crystal not a Uq'(g) crystal. Really what one does it take tensor products `B^{r,s} \otimes u\Lambdawith\Lambdaof levels`.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from 7963ea6 to 3b3c0b2

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

3b3c0b2 added weight_lattice_realization to monomial crystals

bsalisbury1 commented 9 years ago

comment:22

It seems the original error in the monomial crystals code is due to an error in the literature about how the weight function is defined for monomial crystals. I've checked

Kang, Kim, and Shin, Modified Nakajima monomials and the crystal B(infinity), J. Alg. 308 (2007), 524-535.
Kashiwara, Realizations of crystals, Contemporary Math. 325 (2003), 133-139.
Kim and Shin, Nakajima monomials, Young walls, and the Kashiwara embedding, J. Alg. 330 (2011), 234-250.
Kim, Monomial realization of crystal graphs for Uq(An1), Math. Ann. 332 (2005), 17-35.
...

In none of these references is there a way to get delta to appear as a weight. Perhaps I've missed a reference that does include this information, but I'm thinking about the problem now and planning to discuss it with Peter TIngley, so hopefully we will have a resolution soon.

bsalisbury1 commented 9 years ago

Changed keywords from crystals to crystals, days65

tscrim commented 9 years ago

comment:23

Replying to @anneschilling:

CrystalOfAlcovePaths fails outright:

No, it does not. You did not send how you made the weight La. I assume you used the weight_lattice and not weight_space (which you have to for this model!!)

Ah, we do need the weight_space, so we should probably make it error out similar for the LS paths if we aren't in the weight space. Also it does work using the extended weight lattice:

sage: La = RootSystem(['A',2,1]).weight_space(extended=True).fundamental_weights()
sage: C = crystals.AlcovePaths(La[0])
sage: C.module_generators[0].f_string([0,1])
((alpha[0], 0), (alpha[0] + alpha[1], 0))
sage: _.weight()
-Lambda[1] + 2*Lambda[2] - delta

We should also explicitly implement a weight_lattice_realization for DirectSumOfCrystals similar to what we did for tensor products.

We have to decide what we want to do with KyotoPathModel and if we want to consider it as a U_q'-crystal or a U_q-crystal. I think the former is what we should do considering it is a tensor product of U_q'-crystals. In any case, we will probably have to do something special for this.

Mathematically speaking, the Kyoto path model is a model in the category of highest weight affine crystals. It is a U_q(g)-crystal not a Uq'(g) crystal. Really what one does it take tensor products `B^{r,s} \otimes u\Lambdawith\Lambdaof levels`.

I agree that it is in highest weight affine crystals, but we don't have a way to get \delta from the elements. The embedding B(\lambda) \to B^{r,s} \otimes B(\mu) has to be as U_q'(g)-crystals as B^{r,s} must be a U_q'(g)-crystal as otherwise it breaks the condition for the weight function. Also if \Lambda is of level s, then \Lambda + k\delta is of level s for all k since <c, \delta> = 0. I still don't quite see how we could figure out what the coefficient of \delta is for an arbitrary element in the Kyoto path model.

Replying to @bsalisbury1:

It seems the original error in the monomial crystals code is due to an error in the literature about how the weight function is defined for monomial crystals. ... In none of these references is there a way to get delta to appear as a weight. Perhaps I've missed a reference that does include this information, but I'm thinking about the problem now and planning to discuss it with Peter Tingley, so hopefully we will have a resolution soon.

I had poked around on this too when I first looked into this ticket and couldn't find anything (I also looked in Level 0 monomial crystals by Hernandez and Kashiwara). Expressing the monomial crystals in the A's isn't a problem since we can just pull the simple roots and \alpha_0 is what contributes to \delta. We can always brute-force this computation for highest weight crystals by taking a path to the highest weight and computing the weight from that, but that is going to be really slow (but it will be correct). I think the best solution is to follow Hernandez and Kashiwara and add a weight attribute to each element of the crystal, which is easy enough to compute on each application of e and f.

Also in a similar vein, I don't think we can compute \delta from doing Epsilon - Phi as Epsilon = \sum_i \epsilon_i \Lambda_i and similar for \Phi (which comes down to the fact that <h_i, \delta> = 0, where h_i is a simple coroot). I think we need to change this, or at least put a stopgap in affine type and the WLR is the extended weight lattice.

bsalisbury1 commented 9 years ago

comment:24

Replying to @tscrim:

Replying to @bsalisbury1:

It seems the original error in the monomial crystals code is due to an error in the literature about how the weight function is defined for monomial crystals. ... In none of these references is there a way to get delta to appear as a weight. Perhaps I've missed a reference that does include this information, but I'm thinking about the problem now and planning to discuss it with Peter Tingley, so hopefully we will have a resolution soon.

I had poked around on this too when I first looked into this ticket and couldn't find anything (I also looked in Level 0 monomial crystals by Hernandez and Kashiwara). Expressing the monomial crystals in the A's isn't a problem since we can just pull the simple roots and \alpha_0 is what contributes to \delta. We can always brute-force this computation for highest weight crystals by taking a path to the highest weight and computing the weight from that, but that is going to be really slow (but it will be correct). I think the best solution is to follow Hernandez and Kashiwara and add a weight attribute to each element of the crystal, which is easy enough to compute on each application of e and f.

I tried doing this using the path to the highest weight vector, but it causes a loop in Sage because of the way the crystal operators are defined in the monomial crystals model. In particular, we need phi to compute the action of the Kashiwara operators, and phi depends on the weight in the B(infinity) model.

tscrim commented 9 years ago

comment:25

Replying to @bsalisbury1:

Replying to @tscrim:

I had poked around on this too when I first looked into this ticket and couldn't find anything (I also looked in Level 0 monomial crystals by Hernandez and Kashiwara). Expressing the monomial crystals in the A's isn't a problem since we can just pull the simple roots and \alpha_0 is what contributes to \delta. We can always brute-force this computation for highest weight crystals by taking a path to the highest weight and computing the weight from that, but that is going to be really slow (but it will be correct). I think the best solution is to follow Hernandez and Kashiwara and add a weight attribute to each element of the crystal, which is easy enough to compute on each application of e and f.

I tried doing this using the path to the highest weight vector, but it causes a loop in Sage because of the way the crystal operators are defined in the monomial crystals model. In particular, we need phi to compute the action of the Kashiwara operators, and phi depends on the weight in the B(infinity) model.

Right...I'm now fairly convinced it will be best to simply store the weight as an attribute of the elements. This might also result in a speedup as we wouldn't need to (re)compute the weight everytime we call phi().

6bbcde06-8197-41f1-b9a3-c998bb839000 commented 9 years ago

comment:26

Replying to @anneschilling:

But in any case, someone should check!

I will check it.

anneschilling commented 9 years ago

comment:27

Right...I'm now fairly convinced it will be best to simply store the weight as an attribute of the elements. This might also result in a speedup as we wouldn't need to (re)compute the weight everytime we call phi().

Ben and I found a different way which fixes the problem. A new commit will follow soon!

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

e0fd559 monomial crystals weight is fixed!!!

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from 3b3c0b2 to e0fd559

anneschilling commented 9 years ago

comment:29

We have the following behavior in root systems (as Travis mentioned):

sage: R = RootSystem(['B',2,1])
sage: La = R.weight_space().basis()
sage: LaE = R.weight_space(extended=True).basis()
sage: La[0] == LaE[0]
True
sage: La[0].parent() == LaE[0].parent()
False

This yields to the behavior that LS paths labeled by extended fundamental weights and nonextended ones are considered to be the same crystal. Should we fix the weight issue or pass another (fake) argument in the init method to distinguish the crystals?

Nicolas, do you have an opinion on the above?

6bbcde06-8197-41f1-b9a3-c998bb839000 commented 9 years ago

comment:30

Replying to @dwbump:

Replying to @anneschilling:

But in any case, someone should check!

I will check it.

I would if I could … I pulled the branch, built and can't run it it because of some problem with ascii_art. I'll make distclean and try again.

I'm a little worried that if the changes required replacing the inner product in weyl_dimension method there could also be failures in weyl_characters.py too which also depend on the same inner product.

anneschilling commented 9 years ago

comment:31

Replying to @dwbump:

Replying to @dwbump:

Replying to @anneschilling:

But in any case, someone should check!

I will check it.

I would if I could … I pulled the branch, built and can't run it it because of some problem with ascii_art. I'll make distclean and try again.

Strange. It works for both myself and Ben.

I'm a little worried that if the changes required replacing the inner product in weyl_dimension method there could also be failures in weyl_characters.py too which also depend on the same inner product.

The only problem with it was that it only worked for the ambient space and we want it for all weight lattices. If that is not an issue for weyl_character, then it hopefully does not change anything there!

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

c8fd060 Alcove paths weights are up to snuff.

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from e0fd559 to c8fd060

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

495fa98 documentation updates

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Changed commit from c8fd060 to 495fa98

bsalisbury1 commented 9 years ago

comment:34

In the last commit, weight_lattice_realization() for DirectSumOfCrystals was added, too.

bsalisbury1 commented 9 years ago

comment:35

Also, original example is now fixed!

sage: C = crystals.infinity.NakajimaMonomials(['A',1,1])
sage: v=C.highest_weight_vector()
sage: v.f(1).weight()+v.f(0).weight()
-delta

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

Branch pushed to git repo; I updated commit sha1. New commits:

`cb09595`	`18453: fixed equality of LS paths issue`
`42ed2f2`	`Merge branch 'public/crystal/18453' of git://trac.sagemath.org/sage into public/crystal/18453`

sagemath / sage

Infinite affine crystals should use extended weight lattice #18453