Hi Travis, 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. Hence I still say (B). 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? -Mike On Sunday, 13 September 2015 16:22:24 UTC-4, Travis Scrimshaw wrote: > > While looking into the code on skew Schur functions, I noticed this: > > elif x in sage.combinat.skew_partition.SkewPartitions(): > import sage.libs.lrcalc.lrcalc as lrcalc > skewschur = lrcalc.skew(x[0], x[1]) > return self._from_dict(skewschur) > > This has the following result: > > sage: s = SymmetricFunctions(QQ).s() > sage: e = SymmetricFunctions(QQ).e() > sage: sp = SkewPartition([[5,3,3,1], [3,2,1]]) > sage: e(s(sp)) > e[2, 1, 1, 1, 1] - e[2, 2, 1, 1] - e[3, 1, 1, 1] + e[3, 2, 1] > sage: e(sp) > e[2, 2, 1, 1] + e[2, 2, 2] + e[3, 1, 1, 1] + 3*e[3, 2, 1] + e[3, 3] + 2*e[ > 4, 1, 1] + 2*e[4, 2] + e[5, 1] > > The skew() function of lrcalc returns the corresponding skew Schur > function, so the above is a bug. My question is should we > > (A) raise an error for skew shapes on all bases, > (B) allow only of the Schur basis, or > (C) construct the skew Schur function and convert to the corresponding > basis. > > I'm not so sure about (C) because this would mean skew partitions behave > very differently than for partitions. I'm leaning towards (B). Thoughts? > > I'm also going to add a method skew_schur() which constructs the skew > Schur function, as to make getting at skew Schur functions easier (there is > also right now the skew_by method, but that acts on elements). > > Best, > Travis > > -- 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.
