Martin Rubey <martin.ru...@math.uni-hannover.de> writes: > "Nicolas M. Thiery" <nicolas.thi...@u-psud.fr> writes: > >> As for posets, I don't know. I would tend to first write a draft of >> the method in Posets, and then decide if the interfaces and >> implementations are similar enough to be shared or not. > > Here goes:
> # http://www.combinatorics.org/Volume_16/PDF/v16i2r9.pdf ... > def promotion(P, e): ... I wonder about the following: maybe those classes that have a promotion method could be "coercible" to a class LinearExtension depending on a poset P, whose elements are linear extensions of P? I.e., LinearExtension could have as input * a standard Young Tableau * a semistandard Young Tableau and an integer n etc. (I know nothing about crystals...) So I could write something like sage: t = Tableau([[1,1,3],[2,3]]) sage: L = LinearExtension((t, 2)) sage: L.promotion() [[1,1,2],[2,3]] Would this make sense? (In particular, I'm not entirely sure whether one would gain anything. I should stress that I'm *not at all* in favour of replacing the existing methods ".promotion", the above is intended as an additional feature.) Martin -- 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.
