Implement Fock space

[tscrim]

In type A. I put this in a new algebras/quantum_groups folder in preparation of Lie algebras and quantum groups #14901.

[andrew.mathas]

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

[tscrim]

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 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}?

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

[git]

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

[tscrim]

I still need to restrict the indices for the general HW representations.

[git]

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

​ac31208	Fixed indexing set and doctest.
​2eaee1b	Converted to the proper indexing set for HW repr.
​772c09b	Merge branch 'public/combinat/regular_partition_tuples' into public/modules/fock_space
​12f1d6b	Added regular partition tuples.

[git]

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

​62afb1b

Added TODO message for HW repr.

[tscrim]

What does the Fock say? It goes #15621 and back to needs review. :p

[git]

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

[git]

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

​a2996e0	Merge branch 'develop' into public/monoids/15289-indexed
​9fe7ae7	Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space

[git]

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

[git]

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

​6875cfb	Merge branch 'develop' into public/monoids/15289-indexed
​8236ecc	Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space

[git]

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

​1818a3e	Merge branch 'develop' into public/monoids/15289-indexed
​b9c7ffc	Merge branch 'public/monoids/15289-indexed' into public/modules/fock_space

[git]

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.

[git]

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

[git]

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

​19f9aa4

Fixed trivial failing doctest.

[git]

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

[git]

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

[git]

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

[git]

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

​ea28348

Fixing import location of prod.

[git]

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.

[git]

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

​61f5579	Merge branch 'public/modules/fock_space' of trac.sagemath.org:sage into public/modules/fock_space
​448c33b	Adding methods for getting the parameter q.

[git]

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

[git]

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

​0136fcb	Merge branch 'public/modules/fock_space' into 7.3.b3
​9632cef	trac 15508 using sorting_key instead of monomial_cmp

[andrew.mathas]

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

[tscrim]

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

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 U_q(sl_n)-repr instead of a U_q(gl_n)-repr. At some point I will find some time to implement the U_q(gl_n) 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 U_q(sl_n)-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 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 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 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.

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.

[tscrim]

PS - I got no merge conflicts when I merged it locally (trac's git doesn't really try any automerging strategies).

[git]

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

[tscrim]

Okay, so I just noticed that beta8 was release 5 hours ago and there is potentially a trivial conflict with #20976...

[andrew.mathas]

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.

[tscrim]

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 of e and f 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 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.

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.

[git]

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.

[tscrim]

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.

[andrew.mathas]

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.

[tscrim]

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.

[andrew.mathas]

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.

[chapoton]

One must find a way to avoid using the cmp= keyword. Maybe dominance order can be given by a key ?

[git]

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

​e265ec6	Merge branch 'public/modules/fock_space' in 7.6.rc0
​973555f	trac 15508 trying to fix a failing doctest in quantum_numbers

[chapoton]

does not apply

[git]

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

[tscrim]

Trivial rebase.

[git]

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

​80a741a	Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space
​b28e040	Initial cleanup of doc.
​55ce0b4	Moving refrences to master list and adding more examples and doc.

[tscrim]

I have finally gotten around to adding a bunch more documentation and examples. Andrew, any other things you want for this ticket in particular?

[git]

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

​ada7e2f

Remove cmp and just use lex sorting.

[tscrim]

I also removed the cmp sorting because lex sorting is the default (total) order on partitions and it respects dominance order.

[chapoton]

does not apply

[git]

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

[git]

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

​deddf49

Use new style of global options.

[chapoton]

does not apply

[git]

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

[git]

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

[chapoton]

does not apply...

[git]

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

[tscrim]

Trivial rebase (references list).

[git]

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

​407c806

Merge branch 'public/modules/fock_space' in 8.1.rc0

[chapoton]

• typo "agianst"

• could we "lazy import" this new things ?

[git]

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

​8e50781	Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space
​c6aec4a	Fixed typo.

[tscrim]

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

[git]

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

​67c6ba0	Adding q-analogs used in quantum groups.
​a898d44	Merge branch 'public/modules/fock_space' of git://trac.sagemath.org/sage into public/modules/fock_space

[tscrim]

Trivial rebase having split off the q-numbers to a separate ticket.

[git]

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

​e908d59	Adding q-analogs used in quantum groups.
​f4bba3e	Merge branch 'public/quantum_groups/q_numbers-25067' into public/modules/fock_space

[git]

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

​b4f73fa

Minor tweaks to documentation

[andrew.mathas]

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.

[tscrim]

Thank you very much.