#18655: MV Polytopes and PBW crystals
-------------------------------------+-------------------------------------
Reporter: dmuthiah | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-7.2
Component: combinatorics | Resolution:
Keywords: days65, sage- | Merged in:
combinat,crystals | Reviewers: Travis Scrimshaw, Ben
Authors: Dinakar Muthiah, | Salisbury
Adam Schultze, Peter Tingley | Work issues:
Report Upstream: N/A | Commit:
Branch: | 0b24161ae121cc0a8dd1a73321be1553f1c9da46
public/crystals/mv_polytopes-18655 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Changes (by bsalisbury1):
* reviewer: Travis Scrimshaw => Travis Scrimshaw, Ben Salisbury
* milestone: sage-7.1 => sage-7.2
Comment:
Hi all,
I have some questions about this code.
- I think that `.star()` is misbehaving. Here is some evidence. Consider
{{{
sage: MV = crystals.infinity.MVPolytopes("A2")
sage: p0 = MV.module_generators[0]
sage: p = p0.f_string([1,2,1,2,2]); p
MV polytope with Lusztig datum (0, 2, 1)
sage: p.star()
MV polytope with Lusztig datum (1, 2, 0)
}}}
However, when I compute by hand (using the PBW rule from Kamnitzer's
paper (based on the work of Lusztig and Berenstein-Zelevinsky)), I believe
the resulting data should actually be `(2,0,3)`. Using the PBW crystal
code:
{{{
sage: B = crystals.infinity.PBW("A2")
sage: b0 = B.module_generators[0]
sage: b = b0.f_string([1,2,1,2,2]); b
PBW monomial with Lusztig datum (0, 2, 1)
sage: b.lusztig_datum(word=[2,1,2])
(3, 0, 2)
}}}
The reversal of the last output should correspond to `p.star()`.
Moreover, when I check against some previously implemented *-crystal code,
it also agrees with my calculation by hand:
{{{
sage: MVs = crystals.infinity.Star(MV)
sage: ps = MVs.module_generators[0].f_string([1,2,1,2,2])
sage: ps
MV polytope with Lusztig datum (2, 0, 3)
sage: Bs = crystals.infinity.Star(B)
sage: bs = Bs.module_generators[0].f_string([1,2,1,2,2])
sage: bs
PBW monomial with Lusztig datum (2, 0, 3)
}}}
Maybe I am misunderstanding how the *-operator is supposed to act?
- Perhaps `braid_move_calculator.py` should go with the Coxeter group
code. I believe it is more robust than simply crystals code, and Coxeter
group users may also find it beneficial.
- Is it possible initialize an MV polytope without applying a string of
crystal operators from the highest weight? If so, tests should be added
that show this behavior. If not, then it may be desirable to users if one
could initialize an MV polytope using polytope vertices or from a Lusztig
datum.
- Less important, but maybe it may be a good idea to group
`pbw_crystal.py` and `pbw_datum.py` into a single file. They are closely
related, so having less files in the crystals folder may be a good idea.
I do not feel very strongly about this, but it is something that came up.
Thanks for working on this!! This patch will be a spectacular addition to
Sage when it is completed!
--
Ticket URL: <http://trac.sagemath.org/ticket/18655#comment:9>
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.
