#15508: Implement Fock space
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: algebra | Resolution:
Keywords: Fock space | Merged in:
quantum group representations |
Authors: Travis Scrimshaw | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/modules/fock_space | 9632cef81ef0ff0de2d1d2b4461fca7fd146f22e
Dependencies: #15289 #15525 | Stopgaps:
#15621 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:31 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
> {{{#!sage
> |4> + q*|2, 2>
> }}}
> would be reasonable output but, sorry!, I now think that it would be
better to have something like
> {{{#!sage
> F(4) + q*F(2, 2)
> }}}
> with the option of having less condensed output that could be cut-and-
pasted back into sage like:
> {{{#!sage
> 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
> 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
> 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
> 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.
--
Ticket URL: <https://trac.sagemath.org/ticket/15508#comment:32>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
