(C1) display2d:false;
(D1) FALSE
(C2) psi(yb,n):=yb^n/(n*(1/2-(yb+1)/((yb+1)^2+1))^(n/2));
(D2) PSI(yb,n):=yb^n/(n*(1/2-(yb+1)/((yb+1)^2+1))^(n/2))
(C3) taylor(psi(yb,2),yb,0,1);
(D3) +0
(C4) taylor(ratsimp(psi(yb,2)),yb,0,1);
(D4) 2+2*yb
(which is correct)
Martin
Logged In: YES
user_id=651552
In fact, that was only half the story: Taylor always gives zero when the order of
expansion is one less than the second argument to psi. I tried to set taylordepth to a
higher value, but that doesn't change anything...
(C3) taylor(psi(yb,5),yb,0,4);
(D3) +0
(C4) taylor(psi(yb,5),yb,0,5);
(D4) 32/5+16*yb+20*yb^2+14*yb^3+23*yb^4/4+43*yb^5/40
unfortunately, the ratsimp trick doesn't work here:
(C5) taylor(ratsimp(psi(yb,5)),yb,0,5);
TAYLOR encountered an unfamiliar singularity in:
ABS(yb)
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
Martin
On looking at this again, it seems that the problem is that psi(yb, n) is undefined at zero. If psi is redefined (e.g. via ratsimp) in such a way as to make it defined at zero, the problem goes away. Another way to avoid the undefined point is to expand around a point "a" and then take the limit as a goes to zero. So if I were going to try to fix it, I would look first at how taylor handles errors when evaluating at the given point.
Another problem observed: with the stated definition of psi,
causes a stack overflow (Maxima 5.29+commits, ECL 12.2.1).
The stack overflow is avoided with the patch I posted last night to bug 2520 (although this just causes taylor to error out). Probably an improvement, but still not great.