Hi Nicolas,
On 8/26/11 7:45 AM, Nicolas M. Thiery wrote:
On Fri, Aug 26, 2011 at 07:28:14AM -0700, Anne Schilling wrote:
Great! I suppose in type C you would go to symmetric cores
(as in my paper with Thomas and Mark). Where should the
inverse function go, that is, the function from symmetric
cores to affine Grassmannian elements in type C? Also in the
Core class? But then the function would have to take another
argument, namely the type and do some checking (that the core is
symmetric etc).
We can ask Brant and Steve! I agree they are not difficult
to implement, I am just wondering where precisely to put them
in sage.
I guess I would just put them in FiniteWeylGroups, with an
assert self.is_grassmanian(side=...)
and, for the time being, a test on the type. If we start having them
for many types and it gets too clumsy, we can do later as we did for
stanley symmetric functions.
Why FiniteWeylGroups? These are for the affine case. Grassmannian means
that every reduced word ends in 0. I was thinking of putting the code in
sage.combinat.root_system.weyl_group.WeylGroupElement. Or should this go
into the category as the Stanley symmetric functions?
Will the cores for all types use the same Core class?
I guess. I am not sure yet. k-bounded partitions are now just partitions,
so it would be similar. Is this ok?
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.
