#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 | e0ea20cf70e5df0525615683ec82c127b62b3acd
Dependencies: #15289 #15525 | Stopgaps:
#15621 |
-------------------------------------+-------------------------------------
Comment (by andrew.mathas):
Replying to [comment:35 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
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.
--
Ticket URL: <https://trac.sagemath.org/ticket/15508#comment:36>
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.
