#11546: Implementation of energy function for crystals
-----------------------------+----------------------------------------------
Reporter: aschilling | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.7.2
Component: combinatorics | Keywords: energy, crystals
Work_issues: | Upstream: N/A
Reviewer: | Author: Anne Schilling
Merged: | Dependencies:
-----------------------------+----------------------------------------------
Changes (by aschilling):
* status: needs_info => needs_review
Comment:
Hi Tom,
Thank you for looking at the patch!
Replying to [comment:4 sdenton]:
> 1) Funny problem with the classical crystal command, unrelated to patch?
> K.classical_decomposition seems to work fine, though.
>
>
> {{{
> sage: K = KirillovReshetikhinCrystal(['A',2,1],2,1)
> sage: Kc=K.classical_crystal()
> sage: Kc
> ERROR: An unexpected error occurred while tokenizing input
> The following traceback may be corrupted or invalid
> The error message is: ('EOF in multi-line statement', (396, 0))
>
>
---------------------------------------------------------------------------
> AttributeError Traceback (most recent
call last)
> ....
> AttributeError: 'int' object has no attribute 'value'
>
> }}}
classical_crystal is an attribute, not a method, so the correct way of
using it is
{{{
sage: K = KirillovReshetikhinCrystal(['A',2,1],2,1)
sage: Kc = K.classical_crystal
sage: Kc
The crystal of tableaux of type ['A', 2] and shape(s) [[1, 1]]
}}}
> 2) small request... Could there be a 'level' function on KR crystals?
It looks like this would be as easy as wrapping the assertion in the
energy function in a separate function, and would give a natural response
to the user when the 'All crystals in the tensor product need to be
perfect of the same level' assertion error comes up.
The notion of level really only exists for perfect crystals. However, the
method affine_grading also works in the non-perfect setting. Note that in
the assert there is no ceiling for the quotient!
> 3) The 'list' option removed from the 'to_highest_weight' functions
looks like it was a bit of extraneous code, so this is good!
> I'm a little concerned though, because the old way returned:
>
> {{{
> return self.to_highest_weight(list = list + [i], index_set =
index_set)
> }}}
>
> While the new returns:
>
> {{{
> hw = self.to_highest_weight(index_set = index_set)
> return [hw[0], [i] + hw[1]]
> }}}
Doing it this way gives the same output as before! I did not change any of
the tests and they still pass.
> It looks like the new 'i' is being added to opposite ends of the list in
these two cases; is this consistent one way or the other across the code-
base?
>
> This reminds me of a functionality extension I had thought would be nice
at one point, namely being able to feed a list to the 'e' and 'f'
functions instead of just a single letter. It would both extend the
functionality a bit and establish a convention for which way this 'list'
should be applied!
This already exists and is used as follows:
{{{
sage: K = KirillovReshetikhinCrystal(['A',2,1],1,1)
sage: t = K(rows=[[1]])
sage: t.f_string([1,2])
[[3]]
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11546#comment:5>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
