Opened 7 years ago
Closed 3 years ago
#15508 closed enhancement (fixed)
Implement Fock space
Reported by: | tscrim | Owned by: | sage-combinat |
---|---|---|---|
Priority: | major | Milestone: | sage-8.2 |
Component: | algebra | Keywords: | Fock space quantum group representations |
Cc: | sage-combinat, andrew.mathas, aschilling, bsalisbury1 | Merged in: | |
Authors: | Travis Scrimshaw | Reviewers: | Andrew Mathas |
Report Upstream: | N/A | Work issues: | |
Branch: | b4f73fa (Commits) | Commit: | b4f73fab103d4b2912d247590c90ec6b29a7a072 |
Dependencies: | #25067 | Stopgaps: |
Description
In type A. I put this in a new algebras/quantum_groups
folder in preparation of Lie algebras and quantum groups #14901.
Change History (74)
comment:1 Changed 7 years ago by
- Status changed from new to needs_review
comment:2 follow-up: ↓ 3 Changed 7 years ago by
comment:3 in reply to: ↑ 2 Changed 7 years ago by
Hey Andrew,
Replying to andrew.mathas:
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
comment:4 Changed 7 years ago by
- Milestone changed from sage-6.0 to sage-6.1
comment:5 Changed 7 years ago by
- Dependencies changed from #15289 to #15289 #15525
- Status changed from needs_review to needs_work
comment:6 Changed 7 years ago by
- Commit changed from 4548a5b5788962a11afdb40c2786d816cda07183 to 1daad96e45b39257a6a62d75e1ac5d46b57417a3
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
|
comment:7 Changed 7 years ago by
I still need to restrict the indices for the general HW representations.
comment:8 Changed 7 years ago by
- Commit changed from 1daad96e45b39257a6a62d75e1ac5d46b57417a3 to ac31208d6303fb0f5a8c23089b878d2d2480e54f
comment:9 Changed 7 years ago by
- Commit changed from ac31208d6303fb0f5a8c23089b878d2d2480e54f to 62afb1bdf6b1e8eb718c9b30ed059db8917ead21
Branch pushed to git repo; I updated commit sha1. New commits:
62afb1b | Added TODO message for HW repr.
|
comment:10 Changed 7 years ago by
- Dependencies changed from #15289 #15525 to #15289 #15525 #15621
- Status changed from needs_work to needs_review
What does the Fock say? It goes #15621 and back to needs review. :p
comment:11 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:12 Changed 7 years ago by
- Commit changed from 62afb1bdf6b1e8eb718c9b30ed059db8917ead21 to d2f6254ee15b765a306af3ca8def02426e27a767
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
|
comment:13 Changed 7 years ago by
- Commit changed from d2f6254ee15b765a306af3ca8def02426e27a767 to 9fe7ae77b6031d84b048ce3659cb9d3853041f08
comment:14 Changed 7 years ago by
- Commit changed from 9fe7ae77b6031d84b048ce3659cb9d3853041f08 to 83b2766c35ca6b20e4b2efe2d61ccb306c982de2
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
|
comment:15 Changed 7 years ago by
- Commit changed from 83b2766c35ca6b20e4b2efe2d61ccb306c982de2 to 8236ecc05df78b46b7bf59db4678cc2fe4cad858
comment:16 Changed 7 years ago by
- Commit changed from 8236ecc05df78b46b7bf59db4678cc2fe4cad858 to b9c7ffce355173384532ad7655afcb66addc35cc
comment:17 Changed 7 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:18 Changed 7 years ago by
- Commit changed from b9c7ffce355173384532ad7655afcb66addc35cc to 013d996e3994561be0a27ded6d7dc7714b6cc26b
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.
|
comment:19 Changed 7 years ago by
- Commit changed from 013d996e3994561be0a27ded6d7dc7714b6cc26b to cd988b711aa3f5c6506b3e7320c97f93ba25fc05
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
|
comment:20 Changed 7 years ago by
- Commit changed from cd988b711aa3f5c6506b3e7320c97f93ba25fc05 to 19f9aa417a008ea5c5620e3597422d823230db00
Branch pushed to git repo; I updated commit sha1. New commits:
19f9aa4 | Fixed trivial failing doctest.
|
comment:21 Changed 6 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:22 Changed 6 years ago by
- Commit changed from 19f9aa417a008ea5c5620e3597422d823230db00 to de223d428af00af5179c99ccbedb9989e5751d6d
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
|
comment:23 Changed 6 years ago by
- Cc aschilling added
comment:24 Changed 6 years ago by
- Commit changed from de223d428af00af5179c99ccbedb9989e5751d6d to e182d6fc047918f401b5dcbd9b8ea3186e91af3c
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
|
comment:25 Changed 5 years ago by
- Commit changed from e182d6fc047918f401b5dcbd9b8ea3186e91af3c to 8d30b066d0068ad94e1b8d5ac9601c775630a436
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
|
comment:26 Changed 5 years ago by
- Commit changed from 8d30b066d0068ad94e1b8d5ac9601c775630a436 to ea2834853d0e6c78812c645af9a36a4d0aa7b60b
Branch pushed to git repo; I updated commit sha1. New commits:
ea28348 | Fixing import location of prod.
|
comment:27 Changed 5 years ago by
- Commit changed from ea2834853d0e6c78812c645af9a36a4d0aa7b60b to 0274818daff7339be49288ea836f8162a5375fca
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.
|
comment:28 Changed 5 years ago by
- Commit changed from 0274818daff7339be49288ea836f8162a5375fca to 448c33b6533b8488d632bb82079edbc45d63d19f
comment:29 Changed 5 years ago by
- Commit changed from 448c33b6533b8488d632bb82079edbc45d63d19f to 44e05ce2f78bb958e89950666c5d69459d682bb0
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
|
comment:30 Changed 5 years ago by
- Commit changed from 44e05ce2f78bb958e89950666c5d69459d682bb0 to 9632cef81ef0ff0de2d1d2b4461fca7fd146f22e
comment:31 follow-up: ↓ 32 Changed 5 years ago by
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:
- 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?)
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
comment:32 in reply to: ↑ 31 Changed 5 years ago by
Replying to andrew.mathas:
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) TrueOf 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) TrueAgain, 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.
comment:33 Changed 5 years ago by
PS - I got no merge conflicts when I merged it locally (trac's git doesn't really try any automerging strategies).
comment:34 Changed 5 years ago by
- Commit changed from 9632cef81ef0ff0de2d1d2b4461fca7fd146f22e to e0ea20cf70e5df0525615683ec82c127b62b3acd
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
|
comment:35 follow-up: ↓ 36 Changed 5 years ago by
Okay, so I just noticed that beta8 was release 5 hours ago and there is potentially a trivial conflict with #20976...
comment:36 in reply to: ↑ 35 ; follow-up: ↓ 37 Changed 5 years ago by
Replying to tscrim:
Okay, so I just noticed that beta8 was release 5 hours ago and there is potentially a trivial conflict with #20976...
I must have done something strange (again!) as I was having non-trivial merges with beta7...
Also, I fully agree that keeping the notation
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>
as a print option, arguably even the default, is a good idea.
Whoops, forgot
rank = n - 1
.
In the Kac-Moody world I think that rank=n
is correct. In the example above, I thought that only .f(0)
, .f(1)
and .f(2)
should work, but not .f(4)
, .f(5)
etc.
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.
The full Fock space is a a U_q(\widehat{sl}_n)
-module, it's just not irreducible, and the action of e
and f
is what you have implemented. If you are able to implement the full U_q(\widehat{gl}_n)
action that would be awesome, although I think this will be hard. I can implement the canonical basis for U_q(\mathfrak{gl}_\infty)
, but I would need to think/read about how to do the full U_q(\mathfrak{gl}_\infty)
-action.
How about
inject_bases
? Although this isn't future-proof.
Yes, I like this.
comment:37 in reply to: ↑ 36 Changed 5 years ago by
- Milestone changed from sage-6.4 to sage-7.3
Replying to andrew.mathas:
Replying to tscrim:
Whoops, forgot
rank = n - 1
.In the Kac-Moody world I think that
rank=n
is correct. In the example above, I thought that only.f(0)
,.f(1)
and.f(2)
should work, but not.f(4)
,.f(5)
etc.
Ah, I thought you were referring to the (usual matrix) rank of the Cartan matrix. I think it is better to have the rank = n
(i.e., the Kac-Moody version), and I will make sure this is well-documented.
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.
The full Fock space is a a
U_q(\widehat{sl}_n)
-module, it's just not irreducible, and the action ofe
andf
is what you have implemented.
Yes, right. I either ended up misremembering things or was thinking in terms of irreducibility. Thinking about it more (and correctly now), it would be good to have the approximation and upper global crystal bases as bases for the full Fock space, with appropriate error messages for the cases where they are not implemented. I am thinking we should keep the irreducible part as well so we could make more of a connection with the actual crystals later on in the form of explicitly computing the Kashiwara operators. Do you agree?
If you are able to implement the full
U_q(\widehat{gl}_n)
action that would be awesome, although I think this will be hard. I can implement the canonical basis forU_q(\mathfrak{gl}_\infty)
, but I would need to think/read about how to do the fullU_q(\mathfrak{gl}_\infty)
-action.
I think this is doable, but it would require quite a bit of work (and whose knows how computationally feasible it would be). Definitely things for follow-up tickets.
comment:38 Changed 5 years ago by
- Commit changed from e0ea20cf70e5df0525615683ec82c127b62b3acd to 17b9195dd7f45425c92748ae6b3033d8e8d70a41
Branch pushed to git repo; I updated commit sha1. New commits:
8aad63b | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space
|
9afd2d6 | Adding documentation and bases to the Fock space.
|
17b9195 | Changing input for e/f/h methods and adding extra display options.
|
comment:39 Changed 5 years ago by
So I've now rebased to beta8 and done the following changes:
- After a lot of thought, I have decided to remove the highest weight modules (for now) because all of the functionality is in the basis transition code and the extra complication isn't worth it as it worked OOTB. If there is a good use-case for having them, it is easy enough to add them back in later. Moreover, I did not include a dependency on #20564.
- I added fancy ascii/unicode-art output for the Fock space. I fixed an issue with the unicode art for (skew) partitions along the way.
- I did all of the other changes recommended above except I used
inject_shorthands
following symmetric functions and Iwahori-Hecke algebras.
I still need to add examples and some more documentation, but let me know if there's any additional functionality changes/additions that you want.
comment:40 follow-up: ↓ 41 Changed 5 years ago by
Sorry, I haven't had time to look through this properly yet. By removing the highest weight module I assume hat you don't mean taking out the computation of the canonical basis? Assuming so everything you propose sounds good.
comment:41 in reply to: ↑ 40 ; follow-up: ↓ 42 Changed 5 years ago by
Replying to andrew.mathas:
Sorry, I haven't had time to look through this properly yet.
Not a problem. I saw you were busy with the shifted tableaux.
By removing the highest weight module I assume hat you don't mean taking out the computation of the canonical basis? Assuming so everything you propose sounds good.
Yes, that is correct. The computation of the canonical basis is now done directly by the Fock space.
Also, I forgot to mention/ask: what should the shorthand for the natural basis be? I chose it to be F
for "Fock", but I have no good reason to keep with that.
comment:42 in reply to: ↑ 41 Changed 5 years ago by
Replying to tscrim:
Yes, that is correct. The computation of the canonical basis is now done directly by the Fock space.
Great. Happy with that.
Also, I forgot to mention/ask: what should the shorthand for the natural basis be? I chose it to be
F
for "Fock", but I have no good reason to keep with that.
I think F
is good. I don't know of a better name.
comment:43 Changed 4 years ago by
One must find a way to avoid using the cmp=
keyword. Maybe dominance order can be given by a key ?
comment:44 Changed 4 years ago by
- Commit changed from 17b9195dd7f45425c92748ae6b3033d8e8d70a41 to 973555f6c7aeb0b16b9e093642bbcc109bf962ee
comment:45 Changed 4 years ago by
- Milestone changed from sage-7.3 to sage-8.0
- Status changed from needs_review to needs_work
does not apply
comment:46 Changed 4 years ago by
- Commit changed from 973555f6c7aeb0b16b9e093642bbcc109bf962ee to 3f517bf401c9e4b9c8a71057f7c5e97ee96dd50b
Branch pushed to git repo; I updated commit sha1. New commits:
3f517bf | Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space
|
comment:48 Changed 4 years ago by
- Commit changed from 3f517bf401c9e4b9c8a71057f7c5e97ee96dd50b to 55ce0b4f43ee92d893663bbb48c0845876a2c4fa
comment:49 Changed 4 years ago by
- Cc bsalisbury1 added
I have finally gotten around to adding a bunch more documentation and examples. Andrew, any other things you want for this ticket in particular?
comment:50 Changed 4 years ago by
- Commit changed from 55ce0b4f43ee92d893663bbb48c0845876a2c4fa to ada7e2fe10677bfafd073b7c3449bbd72cfbbd7a
Branch pushed to git repo; I updated commit sha1. New commits:
ada7e2f | Remove cmp and just use lex sorting.
|
comment:51 Changed 4 years ago by
I also removed the cmp
sorting because lex sorting is the default (total) order on partitions and it respects dominance order.
comment:53 Changed 3 years ago by
- Commit changed from ada7e2fe10677bfafd073b7c3449bbd72cfbbd7a to 381e45bbb81521f30b99cecb84014529a40315b7
Branch pushed to git repo; I updated commit sha1. New commits:
381e45b | Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space
|
comment:54 Changed 3 years ago by
- Milestone changed from sage-8.0 to sage-8.1
- Status changed from needs_work to needs_review
comment:55 Changed 3 years ago by
- Commit changed from 381e45bbb81521f30b99cecb84014529a40315b7 to deddf4918eb344b239cb8e0cdd09682d98208918
Branch pushed to git repo; I updated commit sha1. New commits:
deddf49 | Use new style of global options.
|
comment:56 Changed 3 years ago by
- Dependencies #15289 #15525 #15621 deleted
- Status changed from needs_review to needs_work
does not apply
comment:57 Changed 3 years ago by
- Commit changed from deddf4918eb344b239cb8e0cdd09682d98208918 to ae8f8045b501713036f2cddf6ac0b8d195edbf20
Branch pushed to git repo; I updated commit sha1. New commits:
ae8f804 | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space
|
comment:58 Changed 3 years ago by
- Status changed from needs_work to needs_review
comment:59 Changed 3 years ago by
- Commit changed from ae8f8045b501713036f2cddf6ac0b8d195edbf20 to 5c6e93fa1e7d2f48f02cb315389000219e0d74a1
Branch pushed to git repo; I updated commit sha1. New commits:
5c6e93f | Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space
|
comment:61 Changed 3 years ago by
- Commit changed from 5c6e93fa1e7d2f48f02cb315389000219e0d74a1 to c101a33b2a7f6e2c09adbb15b12fc0b3c10297fc
Branch pushed to git repo; I updated commit sha1. New commits:
c101a33 | Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space
|
comment:62 Changed 3 years ago by
- Status changed from needs_work to needs_review
Trivial rebase (references list).
comment:63 Changed 3 years ago by
- Commit changed from c101a33b2a7f6e2c09adbb15b12fc0b3c10297fc to 407c80609aed01009119cc09f63e4b2aeae65409
Branch pushed to git repo; I updated commit sha1. New commits:
407c806 | Merge branch 'public/modules/fock_space' in 8.1.rc0
|
comment:64 follow-up: ↓ 66 Changed 3 years ago by
- typo "agianst"
- could we "lazy import" this new things ?
comment:65 Changed 3 years ago by
- Commit changed from 407c80609aed01009119cc09f63e4b2aeae65409 to c6aec4a3291f1e9beea4ce1d2205cfc0924e41cd
comment:66 in reply to: ↑ 64 Changed 3 years ago by
Replying to chapoton:
- typo "agianst"
Fixed.
- could we "lazy import" this new things ?
The only thing added to the global namespace is FockSpace
, which is lazily imported. The quantum_groups/all.py
file is not, but IMO, that should not be lazily imported (and we do not do that anywhere else).
comment:67 Changed 3 years ago by
- Commit changed from c6aec4a3291f1e9beea4ce1d2205cfc0924e41cd to a898d44a1b12871ea632e17fe94dceaa454f6356
comment:68 Changed 3 years ago by
- Dependencies set to #25067
- Milestone changed from sage-8.1 to sage-8.2
Trivial rebase having split off the q-numbers to a separate ticket.
comment:69 Changed 3 years ago by
- Commit changed from a898d44a1b12871ea632e17fe94dceaa454f6356 to f4bba3e18d34583b76c9df8cab80ff469495635f
comment:70 Changed 3 years ago by
- Commit changed from f4bba3e18d34583b76c9df8cab80ff469495635f to b4f73fab103d4b2912d247590c90ec6b29a7a072
Branch pushed to git repo; I updated commit sha1. New commits:
b4f73fa | Minor tweaks to documentation
|
comment:71 Changed 3 years ago by
The code looks good. I have made a few minor tweaks to the documentation and changed the hi
method to the more descriptive h_inverse
. If you are happy with these, and all tests pass, then please consider this a positive review.
comment:72 Changed 3 years ago by
- Reviewers set to Andrew Mathas
- Status changed from needs_review to positive_review
comment:73 Changed 3 years ago by
Thank you very much.
comment:74 Changed 3 years ago by
- Branch changed from public/modules/fock_space to b4f73fab103d4b2912d247590c90ec6b29a7a072
- Resolution set to fixed
- Status changed from positive_review to closed
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):
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}
?sage
(for a suitably defined shortcutF
).Cheers, Andrew