On 1/26/11 2:13 PM, Nicolas M. Thiery wrote:
On Sun, Jan 23, 2011 at 09:57:36PM -0800, Anne Schilling wrote:
One problem with this is, that the list of shapes option is heavily
used in the construction of KR crystals, as first their classical
crystal structure is defined and then the 0-arrows are constructed
on top of this.
Sure.
The final result is not a direct sum of crystals, so I would not
like to have this as the data structure. It is only an intermediate
trick to construct them.
This technical information seems fairly encapsulated to me, since the
classical crystal D and its affine counterpart C are clearly
separated. Indeed, the relation between elements of C and of D is that
x contains an element of D (in x.value/x.lift()) [1], not that x is an
element of D (as if there was an inheritance relation) [2].
So D can be a direct sum without imposing C to be.
Ok, thanks.
Besides, the direct sum approach would allow for creating affine
crystals where the classical structure has several highest vectors of
same weight (or does the current code already uses a trick for those?)
This is not needed since they all appear with multiplicity one.
So I left this for now, since there is currently no need for this
except in this application where everything works. If at some point
we need a more general set-up, it should be easy to upgrade.
Cheers,
Anne
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
