Hey Mike, I would say that the skew partition input into bases (other than Schur > functions, and for Schurs the documentation is insufficient...see sf.html) > is undocumented and so the output should be suspect (and not what one would > hope). > > For Schur functions, I think the output is what I would expect and so of > (A), (B) and (C), I think that (B) is the way to go and it should be better > documented. > > I can add a fourth option: > if sp is a skew partition then > (D) basis(sp) returns basis(sp[0]).skew_by(basis.dual_basis()(sp[1])) > This agrees with the definition of the Schur function indexed by a skew > partition and would probably be the most natural analogue of the notation > basis(sp) > I can see two problems with this approach: > (a) I don't know how often "dual_basis" is implemented and > (b) one would need to document and mathematically motivate this notation > and I could see an argument being made for another definition. > > Every classical Sym basis has a dual_basis() implemented, but (b) is definitely more of a sticking point.
> Hence I still say (B). > Then I will do (B) unless anybody has any other suggestions or objections. > > Where are you planning to add the method skew_schur()? Would this go as > a method of the Schur basis or of the symmetric functions? > > I was going to add it to the generic basis code which does the Schur expansion and converts that over to self, just like the carlitz_shareshian_wachs or gessel_reutenauer function. Best, -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
