Revision history [back]
 | 1 | initial version |
If you use u.expand(3) == d^2 (as mentioned in the documentation of from_polynomial) I get equality. With the same trick you can then see what e[4,2].expand(3) is supposed to mean and it seems to be 0. The same for e[4,1,1].expand(3). So, it seems that the routine is at least internally consistent. It shouldn't include 0-functions in its representations, though; that's just confusing.
I suspect what's happening: it's converting to symmetric functions through another basis (monomial basis, where the indexing is by a non-increasing exponent vector, taken to be the exponents of the leading monomial) and then it converts to the elementary basis in a way that's valid for symmetric functions in an arbitrary number of variables, at the cost of including loads of 0 terms for particular realizations (fair enough, because at this point the system doesn't know the number of variables that the symmetric function is in any more)
It looks like u.restrict_parts(3) culls the bits you're not interested in.
I've seen this before: in principle combinatorics and algebra mean the same thing when they talk about symmetric functions, but their motivating questions for studying the two are so different that their notations and conventions diverge to the point of being incompatible.
| | 2 | No.2 Revision |
If you use u.expand(3) == d^2 (as mentioned in the documentation of from_polynomial) I get equality. With the same trick you can then see what e[4,2].expand(3) is supposed to mean and it seems to be 0. The same for e[4,1,1].expand(3). So, it seems that the routine is at least internally consistent. It shouldn't include 0-functions in its representations, though; that's just confusing.
I suspect what's happening: it's converting to symmetric functions through another basis (monomial basis, where the indexing is by a non-increasing exponent vector, taken to be the exponents of the leading monomial) and then it converts to the elementary basis in a way that's valid for symmetric functions in an arbitrary number of variables, at the cost of including loads of 0 terms for particular realizations (fair enough, because at this point the system doesn't know the number of variables that the symmetric function is in any more)
It looks like u.restrict_parts(3) culls the bits you're not interested in.
I've seen this before: in principle combinatorics and algebra mean the same thing when they talk about symmetric functions, but their motivating questions for studying the two them are so different that their notations and conventions diverge to the point of being incompatible.
