Closed tscrim closed 6 years ago
Hi Travis,
Thanks for both working on this and for letting me know about it. I just had a quick glance through it and it looks very nice, but there is a lot of code to digest! The fact that the new improved git-world makes it difficult to separate the current ticket from its dependencies makes this harder of course. I will try and look through this properly in due course as it is one of the things that I care about - and implementing this was on my to-do list.
A few questions/comments (based on my very quick read through):
I noticed that you have implemented Fayer's LLT algorithm for computing the canonical bases of the combinatorial Fock spaces. I haven't looked at all at the details of your code but in his paper Fayers' has a conjecture for the degrees of the polynomials that came up (they should always be less than the defect/weight), and he mentioned that if this conjecture were true then there are some shortcuts which speed up his algorithm. Fayers' conjecture is now known to be true, so I was wondering whether you have used this in your code.
Am I right in thinking that you have only implemented the Fock spaces F(\Lambda)
such that F(\Lambda)\cong F(\Lambda_{a_1})\otimes\dots\otimes F(\Lambda_{a_k})
, for dominant weights \Lambda=\Lambda_{a_1}+\dots+\Lambda_{a_k}
?
In addition to these "standard" Fock spaces there are some more general Fock spaces for U_q(\widehat{sl}_e)
defined by Uglov. I am asking this more for information/clarification as Uglov's Fock spaces don't come up in my work - they arise in the cateogorification of rational Cherednik algebras.
In terms of displaying the elements of the Fock space I think that
|[3, 1]> + q*|[2, 2]> + q^ 2*|[2, 1, 1]>
is too cumbersome. I would prefer something like
|3, 1> + q*|2, 2> + q^ 2*|2, 1, 1>
and something similar for higher levels. Other alternatives would be
F(3, 1) + q*F(2, 2) + q^ 2*F(2, 1, 1)
or
F([3, 1]) + q*F([2, 2]) + q^ 2*F([2, 1, 1])
which both have the distinct advantage that you can cut and paste the output back into sage
(for a suitably defined shortcut F
).
Cheers, Andrew
Hey Andrew,
Replying to @AndrewAtLarge:
Thanks for both working on this and for letting me know about it. I just had a quick glance through it and it looks very nice, but there is a lot of code to digest! The fact that the new improved git-world makes it difficult to separate the current ticket from its dependencies makes this harder of course.
Actually, there's not a functional dependency on #15289, just some syntax, so I can commute this past with relative ease if #15289 doesn't get reviewed before we are done with this.
I will try and look through this properly in due course as it is one of the things that I care about - and implementing this was on my to-do list.
A few questions/comments (based on my very quick read through):
- [I]n his paper Fayers' has a conjecture for the degrees of the polynomials that came up (they should always be less than the defect/weight), ... Fayers' conjecture is now known to be true, so I was wondering whether you have used this in your code.
No I do not. Currently I don't check if a partition is regular, so I guess I'm really computing for the full tensor product space. I should also note another abuse; my indexing set for the highest weight modules is too large (I'm using all partitions instead of just the n
-regular and giving an error when the user tries to create a non-n
-regular partition). I probably should change that...
>.>
<.<
- Am I right in thinking that you have only implemented the Fock spaces
F(\Lambda)
such thatF(\Lambda)\cong F(\Lambda_{a_1})\otimes\dots\otimes F(\Lambda_{a_k})
, for dominant weights\Lambda=\Lambda_{a_1}+\dots+\Lambda_{a_k}
?
Correct.
In addition to these "standard" Fock spaces there are some more general Fock spaces for
U_q(\widehat{sl}_e)
defined by Uglov. I am asking this more for information/clarification as Uglov's Fock spaces don't come up in my work - they arise in the cateogorification of rational Cherednik algebras.
Hmm...interesting. Do you have a reference I could look at?
- In terms of displaying ... I would prefer something like
|3, 1> + q*|2, 2> + q^ 2*|2, 1, 1>
and something similar for higher levels.
I will make this change along with restricting the indexing set to the proper set.
Best,
Travis
Changed dependencies from #15289 to #15289 #15525
Branch pushed to git repo; I updated commit sha1. New commits:
1daad96 | Changes to term formatting and restricted some indexing sets. |
f5a794b | Merge branch 'public/combinat/partitions_constraints-15525' into public/modules/fock_space |
1adb368 | Added deprecation to IntegerListLex global_options arg. Fixed doctests. |
2341248 | Merge branch 'public/combinat/partitions_constraints-15525' into public/modules/fock_space |
4143c96 | Merge branch 'develop' into public/combinat/partitions_constraints-15525 |
976a4d1 | Merge branch 'public/combinat/partitions_constraints-15525' into public/modules/fock_space |
82d7b6f | Merge branch 'master' into public/modules/fock_space |
7982d3a | Iniital fix and added regular partitions. |
3597354 | Merge branch 'master' into public/modules/fock_space |
I still need to restrict the indices for the general HW representations.
Branch pushed to git repo; I updated commit sha1. New commits:
62afb1b | Added TODO message for HW repr. |
Changed dependencies from #15289 #15525 to #15289 #15525 #15621
What does the Fock say? It goes #15621 and back to needs review. :p
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
991953a | Merge branch 'develop' into public/monoids/15289-indexed |
b51bc3d | Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space |
f13f9ad | Merge branch 'develop' into public/modules/fock_space |
bd82ed8 | Merge branch 'develop' into public/monoids/15289-indexed |
56703eb | Made Indexed* have entry points through Free*. |
163df6e | Changed more _basis_keys to _indices, deprecated the former. |
8db8e0a | Changed `_an_element_` to indexed_monoid.py. |
760c939 | Merge branch 'public/monoids/15289-indexed' of trac.sagemath.org:sage into public/monoids/15289-indexed |
03057a4 | Merge branch 'develop' into public/monoids/15289-indexed |
d2f6254 | Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space |
Branch pushed to git repo; I updated commit sha1. New commits:
fa37724 | Merge branch 'develop' into public/modules/fock_space |
c1cc341 | Merge branch 'develop' into public/monoids/15289-indexed |
49068b2 | Merge branch 'develop' into public/monoids/15289-indexed |
83b2766 | Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space |
Branch pushed to git repo; I updated commit sha1. New commits:
1c1b4eb | Changed monomial_cmp to generator_cmp and added free (static)method to monoids and groups category. |
47b5be7 | Removed `__contains__` and fix monomial_cmp in indexed_monoid.py |
4097a8c | Merge branch 'develop' into public/monoids/15289-indexed |
23301a8 | Misc fixes and tweaks. |
3884291 | Merge branch 'develop' into public/monoids/15289-indexed |
faea728 | Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space |
cf852d5 | Merge branch 'develop' into public/modules/fock_space |
013d996 | Fixed doctest. |
Branch pushed to git repo; I updated commit sha1. New commits:
cd988b7 | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space |
Branch pushed to git repo; I updated commit sha1. New commits:
19f9aa4 | Fixed trivial failing doctest. |
Branch pushed to git repo; I updated commit sha1. New commits:
de223d4 | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space |
Branch pushed to git repo; I updated commit sha1. New commits:
c477d6c | Merge branch 'public/combinat/partitions_constraints-15525' of trac.sagemath.org:sage into public/combinat/partitions_constraints-15525 |
03dcda9 | Merge branch 'public/combinat/partitions_constraints-15525' of trac.sagemath.org:sage into public/combinat/partitions_constraints-15525 |
e182d6f | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space |
Branch pushed to git repo; I updated commit sha1. New commits:
2ec0a28 | Merge branch 'public/combinat/regular_partition_tuples' of git://trac.sagemath.org/sage into public/combinat/regular_partition_tuples |
8d30b06 | Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space |
Branch pushed to git repo; I updated commit sha1. New commits:
ea28348 | Fixing import location of prod. |
Branch pushed to git repo; I updated commit sha1. New commits:
2fda619 | Merge branch 'public/combinat/regular_partition_tuples' of trac.sagemath.org:sage into public/combinat/regular_partition_tuples |
c6a4f44 | Some fixes and tweaks from rebasing. |
340df1b | Adding another doctest for containment. |
c07e17c | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space |
c5c6d4e | Partially fixing some issues. |
809cc13 | Fixing input of TableauxTuple to handle level 1 partition tuple input. |
1c99864 | Merge branch 'public/combinat/regular_partition_tuples' into public/modules/fock_space |
0274818 | Fixing issue with not getting the correct charge for the A -> F transition. |
Branch pushed to git repo; I updated commit sha1. New commits:
44e05ce | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space |
Hi Travis,
I have started to look at this. The first thing that it needs is more documentation at the start of the module as it took me a while to work out what it does, which is quite impressive. Next, I know that I suggested above that
|4> + q*|2, 2>
would be reasonable output but, sorry!, I now think that it would be better to have something like
F(4) + q*F(2, 2)
with the option of having less condensed output that could be cut-and-pasted back into sage like:
F[[4],[3,1]] + q*F[[2, 2,2],[1,1]]
Your implementation makes a clear distinction between the Fock space and the integrable highest weight module that it contains. As the highest weight module embeds into the Fock space you could drop this distinction and instead just allow people to pass from the bases of the highest weight module and the basis of the full Fock space. That is, I am suggesting that for the user you drop the additional layer of complication of having to first construct the Fock space, then the highest weight module and then the bases for this module. That is, o me it feels overly cumbersome to have F[4,2,1]
give an element of the Fock space and then have F.highest_weight_representation().A()[3,1]
and F.highest_weight_representation().G()[3,1]
give the elements of the highest weight rep. There are arguments both ways, and what you have done is certainly fine and it works, so do whatever you think will work best even if that means you ignore with this comment.
In terms of the Fock space, it would be good to have an inject_variables
method -- one way of addressing my comment above (apart from ignoring it!:), would be to have this method inject the highest weight module and its bases into the global namespace.
Next, are the terms of "rank" and "type" that you use inside FockSpace.init that common? I ask because when I first saw them they certainly confused me:) The "rank" is probably fine as I think that it is meant to be the rank of the Kac-Moody algebra, although if this is true then the following seems strange:
sage: F=FockSpace(3); F
Fock space of rank 3 of type (0,) over Fraction Field of Univariate Polynomial Ring in q over Rational Field
sage: F([]).f(0).f(1).f(2).f(3).f(4).f(5)
|6> + q*|5, 1> + q*|3, 2, 1> + q^2*|2, 2, 2>
If n
is the rank that I would think that F(mu).f(i)
should only work for 0\le i <n
, so something seems to be wrong here. Perhaps you always take i
modulo n
? I didn't see this in the code but instead of doing this I rather that the code gave an error when i
was too large rather than have it silently convert i
to an integer mod n
.
I think that "type" should be changed to something else because:
CartanType(['A',n,1])
would be better...although perhaps dominant weights have not been implemented yet?)Final comment for now is that in my Specht package, in gap, I found it really useful to have .e
and .f
work for sequences of "residues". That is,
sage: F(mu).f(i1).f(i2)...f(ik) == F(mu).f(i1,i2,...,ik)
True
Of course have a problem here because F(mu).f(i,m)
corresponds to the divided power F_i^{(m)}
. What do you think of using F(mu).f( (i,m) )
for divided powers and then allowing expressions like the following?
sage: F(mu).f( (i1.m1) ).f( (i2,m2) )...f(ik) \
== F(mu).f( (i1,m1),(i2,m2), i3,...,(ij,mj),...,ik)
True
Again, happy for you to do what yu think is best here.
Could you please add some more documentation on how to use the Fock space code and merge your ticket with the latest develop branch - it's not an automatic merge, so I didn't want to break anything. As part of my review I can add some background material on the applications to the representation theory of the Ariki-Koike algebras.
Andrew
Replying to @AndrewAtLarge:
I have started to look at this. The first thing that it needs is more documentation at the start of the module as it took me a while to work out what it does, which is quite impressive.
Thank you so much for taking a look at this. I will start adding more documentation and examples as soon as I get around to this. I'm planning to use the Kleshchev partitions from #20564 as the indexing set for the higher level representations since I don't want to think of it as a tensor product.
Next, I know that I suggested above that
|4> + q*|2, 2>
would be reasonable output but, sorry!, I now think that it would be better to have something like
F(4) + q*F(2, 2)
with the option of having less condensed output that could be cut-and-pasted back into sage like:
F[[4],[3,1]] + q*F[[2, 2,2],[1,1]]
Would a print option attached to each parent or a global option be okay for this? I actually have grown fond of the current print repr since it is visually close to the literature.
Your implementation makes a clear distinction between the Fock space and the integrable highest weight module that it contains. As the highest weight module embeds into the Fock space you could drop this distinction and instead just allow people to pass from the bases of the highest weight module and the basis of the full Fock space. That is, I am suggesting that for the user you drop the additional layer of complication of having to first construct the Fock space, then the highest weight module and then the bases for this module. That is, o me it feels overly cumbersome to have
F[4,2,1]
give an element of the Fock space and then haveF.highest_weight_representation().A()[3,1]
andF.highest_weight_representation().G()[3,1]
give the elements of the highest weight rep. There are arguments both ways, and what you have done is certainly fine and it works, so do whatever you think will work best even if that means you ignore with this comment.
One of the main reasons why I want to keep them separate is because the Fock space can be larger since it has non-regular partitions as basis elements. The current version of the highest weight representation is only considered as Uq(sln)-repr instead of a Uq(gln)-repr. At some point I will find some time to implement the Uq(gln) case (sorry I haven't Anne!), and at which point, I would have that be a basis for the Fock space. I also am not sure how the natural basis would act under e
/f
, in fact, I am not sure the natural basis makes sense in the Uq(sln)-representation... So I think they should be separate.
In terms of the Fock space, it would be good to have an
inject_variables
method -- one way of addressing my comment above (apart from ignoring it!:), would be to have this method inject the highest weight module and its bases into the global namespace.
What comment, I didn't see a comment <.< >.> :P Although I agree with the principle of it, but I don't think it is the correct name. For symmetric functions, we use inject_shorthands
. How about inject_bases
? Although this isn't future-proof.
Next, are the terms of "rank" and "type" that you use inside FockSpace.init that common? I ask because when I first saw them they certainly confused me:) The "rank" is probably fine as I think that it is meant to be the rank of the Kac-Moody algebra, although if this is true then the following seems strange:
sage: F=FockSpace(3); F Fock space of rank 3 of type (0,) over Fraction Field of Univariate Polynomial Ring in q over Rational Field sage: F([]).f(0).f(1).f(2).f(3).f(4).f(5) |6> + q*|5, 1> + q*|3, 2, 1> + q^2*|2, 2, 2>
Whoops, forgot rank = n - 1
.
If
n
is the rank that I would think thatF(mu).f(i)
should only work for0\le i <n
, so something seems to be wrong here. Perhaps you always takei
modulon
? I didn't see this in the code but instead of doing this I rather that the code gave an error wheni
was too large rather than have it silently converti
to an integer modn
.
I will add the appropriate error checks.
I think that "type" should be changed to something else because:
- it is non-standard and "type" is over-used in mathematics
- type is a reserved word in python (I know you don't use it in the code...)
- I think that (multi)charge or dominant_weight (or an actual dominant weight from
CartanType(['A',n,1])
would be better...although perhaps dominant weights have not been implemented yet?)
I agree. I think I just chose it because it was the most appropriate word I could think of at the time. I will change it to (multi)charge.
Final comment for now is that in my Specht package, in gap, I found it really useful to have
.e
and.f
work for sequences of "residues". That is,sage: F(mu).f(i1).f(i2)...f(ik) == F(mu).f(i1,i2,...,ik) True
Of course have a problem here because
F(mu).f(i,m)
corresponds to the divided powerF_i^{(m)}
. What do you think of usingF(mu).f( (i,m) )
for divided powers and then allowing expressions like the following?sage: F(mu).f( (i1.m1) ).f( (i2,m2) )...f(ik) \ == F(mu).f( (i1,m1),(i2,m2), i3,...,(ij,mj),...,ik) True
Again, happy for you to do what yu think is best here.
I like the idea of doing the tuples for the divided powers. I think it is slightly more natural to have an arbitrary number of integers/tuples than using a list (and it also means less input parsing). Will change.
Could you please add some more documentation on how to use the Fock space code and merge your ticket with the latest develop branch - it's not an automatic merge, so I didn't want to break anything. As part of my review I can add some background material on the applications to the representation theory of the Ariki-Koike algebras.
I will do so as soon as I can. I should have a lot more time over the weekend and into next week.
PS - I got no merge conflicts when I merged it locally (trac's git doesn't really try any automerging strategies).
Branch pushed to git repo; I updated commit sha1. New commits:
e0ea20c | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space |
Okay, so I just noticed that beta8 was release 5 hours ago and there is potentially a trivial conflict with #20976...
In type A. I put this in a new
algebras/quantum_groups
folder in preparation of Lie algebras and quantum groups #14901.Depends on #25067
CC: @sagetrac-sage-combinat @AndrewAtLarge @anneschilling @bsalisbury1
Component: algebra
Keywords: Fock space quantum group representations
Author: Travis Scrimshaw
Branch/Commit:
b4f73fa
Reviewer: Andrew Mathas
Issue created by migration from https://trac.sagemath.org/ticket/15508