#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 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
 {{{#!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]]
 }}}

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

 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

--
Ticket URL: <https://trac.sagemath.org/ticket/15508#comment:31>
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.

Reply via email to