Successive Series Expansion Bug (?)

I've found what appears to be a bug in MMA related to taking successive series expansions. I'm providing this minimal example and post as other posts didn't appear to address the issue I found.

In particular, MMA seems to get confused in keeping track of orders of parameters when future expansion parameters are in the powers of earlier expansion parameters, which seems to be due to a limitation of the SeriesData object that Series produces.

While it appears known that MMA may include extra powers, e.g. Multivariable Taylor expansion does not work as expected, in my example MMA misses some critical terms. For example

Series[x^z y^z (1 + x + y)/z, {x, 0, 0}, {y, 0, 0}, {z, 0, 1}] // Normal


yields the incorrect expression

$$\frac{1}{z}+\log (x)+\log (y) + z \log (x) \log (y)$$

whereas

Series[Series[Series[x^z y^z (1 + x + y)/z, {x, 0, 0}] //
Normal, {y, 0, 0}] //Normal, {z, 0, 1}] // Normal


captures all the correct terms,

$$\frac{1}{z}+\log (x)+\log (y) + \frac{1}{2} z \big( \log ^2(x)+2 \log (x) \log (y)+\log ^2(y) \big).$$

It seems that the critical point is to ensure that one finds the correct answer, each Series[] result needs to be hit with a Normal[] first, before performing the next Series[].

Interestingly, the first method does not miss any terms when I remove the $1/z$ from the expression to be expanded and ask for a series expansion up to $O(z^2)$, although the first method does then give some extra terms $O(z^3)$ and $O(z^4)$, too.

Possibly the bug (?) described above is related to Peculiarities with Series and fractional exponents or bug?.

• Please don't use the BUGS tag until the community find confirmation there is a bug. – rhermans Feb 22 '16 at 10:59
• Someone who has time might ponder Series[x^z y^z (1 + x + y)/z, {z, 0, 1}] // FullForm vs. Series[x^z y^z (1 + x + y)/z, {y, 0, 0}, {x, 0, 0}] // FullForm. – Michael E2 Feb 22 '16 at 11:44
• Hi Michael, according to the MMA documentation, Series evaluates its expansion from left to right; i.e. the two orderings given in my comment are the same. Hi @rhermans, Michael has confirmed the discrepancy. Getting two different results for what should be the same expression seems like a bug to me. – WAH Feb 22 '16 at 14:19
• Per my response, this is not related to that "Pecularities with Series..." post. That one is for a univariate series whereas the difficulties here appear to be strictly a multivariate series phenomenon. – Daniel Lichtblau Feb 22 '16 at 21:56
• Hi Daniel, the similarity here and in "Peculiarities..." is that SeriesData[] is somewhat inflexible in the data it can contain (only rational powers of the small parameter). Thus in the above example SeriesData[] cannot have powers of x^z inside, so it's pulled out front, as seen in FullForm. Subsequent Series[] calls then do not correctly keep track of the expansion order and hence the incorrect result in the above example. – WAH Feb 23 '16 at 12:38

The order of evaluation business is confusing. It really does go from inside outward for Series. We can see this from the example under Generalizations and Extensions on the ref guide page.

Here is the example.

Series[Sin[x + y], {x, 0, 3}, {y, 0, 3}]


First we show the result of handling the variable x.

In[579]:= InputForm[Series[Sin[x + y], {x, 0, 3}]]
Out[579]//InputForm=
SeriesData[x, 0, {Sin[y], Cos[y], -Sin[y]/2, -Cos[y]/6}, 0, 4, 1]


The full result is basically the result of now going inside each series coefficient when handling the y terms.

In[576]:= InputForm[Series[Sin[x + y], {x, 0, 3}, {y, 0, 3}]]
Out[576]//InputForm=
SeriesData[x, 0, {SeriesData[y, 0, {1, 0, -1/6}, 1, 4, 1],
SeriesData[y, 0, {1, 0, -1/2}, 0, 4, 1],
SeriesData[y, 0, {-1/2, 0, 1/12}, 1, 4, 1],
SeriesData[y, 0, {-1/6, 0, 1/12}, 0, 4, 1]}, 0, 4, 1]


When we get to the example from this post, I'm not sure if what we see is a bug or a feature. The InputForm shows some levels of nesting of z that seem amiss. I'll take a closer look if I get a chance.

--- edit ---

It's a feature. Here is a simpler form of the input that elicits the same behavior. I'll show it in two separate steps.

In[1381]:= InputForm[s1 = Series[x^z (1 + x)/z, {x, 0, 0}]]
Out[1381]//InputForm=
x^z*SeriesData[x, 0, {z^(-1)}, 0, 1, 1]


Fine so far, all according to documented behavior. Now try to extract a series in z.

In[1382]:= InputForm[Series[s1, {z, 0, 1}]]
Out[1382]//InputForm=
SeriesData[z, 0,
{SeriesData[x, 0, {SeriesData[z, 0, {1}, -1, 2, 1]}, 0, 1, 1],
SeriesData[x, 0,
{SeriesData[z, 0, {Log[x]}, -1, 2, 1]}, 0, 1, 1]},  0, 2, 1]


We now have nested series in z. While not desirable, I don't see any clean way to circumvent this. The upshot is that, for a nested series, we can expect trouble when an outer series is presented something that has its variable both inside and outside of SeriesData objects.

As noted already in this thread, a viable way around this is to interpose Normal between nested series evaluations.

--- end edit ---

• Hi Daniel, yes, I think you got to the heart of the matter, which is that SeriesData[] doesn't seem to be able to handle certain expressions (as was hinted at by @Michael-E2 and explored further by you). Having multiple SeriesData[] expressions, possibly nested, could be a feature, but it seems MMA is not properly keeping track of orders of parameters, hence the bug that Series[x^z y^z (1 + x + y)/z, {x, 0, 0}, {y, 0, 0}, {z, 0, 1}] yields an incorrect result. (I can't see how an expression yielding the wrong answer is a feature.) – WAH Feb 23 '16 at 12:32
• It's a feature because it is being pushed outside its zone of operation. Per documentation: "Series can construct standard Taylor series, as well as certain expansions involving negative powers, fractional powers, and logarithms." The example in question has essential singularities at the origin in both x and y, as well as a "polynomial" factor. The request is for terms up to order zero, effectively removing an x*y^z and a y*x^z factor. When the process gets around to extracting the series in z we've thus lost what would become logs in x and y. – Daniel Lichtblau Feb 23 '16 at 22:28