Wei Xi Fan

8 Reputation

2 Badges

13 years, 303 days

MaplePrimes Activity


These are replies submitted by Wei Xi Fan

Yes, there is an issue in MultiSeries's handling of LambertW. It becomes evident by comparing the result of the problematic call MultiSeries:-series( (G(1-h^2) + 1)/h, h, 1) and the result of MultiSeries:-series( (G(1-h^2) + 1)/h, h, 2) (the latter is correct).

Note that all MultiSeries:-limit needs is the first term (dominant term) of the series, so it uses a call similar to the problematic calling sequence above, leading to precisely the same problem.

Please note that MultiSeries:-series(f(x), x=0) returns a series that is valid on a real open interval (0, a) for some a > 0. In other words, a series that's valid as x approaches 0 along the positive real axis. The call MultiSeries:-series(f(z), z=z0) for any nonzero complex z0 returns a series that is valid as z approaches z0 along a ray emanating from the origin. This pathwise semantics makes MultiSeries quite useful in avoiding branch cut issues. The example Robert gave is an illustration of this. To obtain a series that is valid along some other path, one simply performs a change of variables as follows:

> dir := -1: #some nonzero complex number, interpreted as a direction vector
> MultiSeries:-series( G( 1 - (dir*h)^2 ), h=0 );

The above call will compute the series as h -> 0+. I've put together a worksheet that visually demonstrates the series approximations to G( 1 - h^2 ) along eight different directions as computed by MultiSeries:-series. It's available here:

View 5819_multiseries.mw on MapleNet or Download 5819_multiseries.mw
View file details

EDIT: I made a mistake in one of the comments in the worksheet. Each finite limit is really just the absolute value of the coefficient of h^3, rather than one-sixth of it. (It is one-sixth of the absolute value of the one-sided third derivative of H(h*dir)).

For more information on this pathwise semantics of MultiSeries, please refer to its help page.

Finally, the limit computation of a 0/0 expression in Maple should not be significantly different from the limit computation of anything else, since the core algorithm in Maple (both in :-limit and MultiSeries:-limit) is based on some form of asymptotic series expansion with machinery in place to detect indefinite cancellation. To find a 0/0 limit, Maple basically divides the series for the numerator by the series for the denominator, and looks at the dominant term of the quotient series. Problems found in 0/0 limit computations most likely indicate that the coefficients were not computed correctly, as in this example.

Victor Fan
Math Group, Maplesoft

This missed case is now tracked in Maple's internal bug-tracking system. Thanks for discovering this :-) .
This missed case is now tracked in Maple's internal bug-tracking system. Thanks for discovering this :-) .
The integration issues mentioned in this post are now tracked in Maple's internal bug tracking system. Thank you all for identifying the problem and isolating a potential cause for the bug. :)
The issue mentioned in this thread is now tracked in Maplesoft's internal bug-tracker. Thank you for taking the time to bring this to our attention.
The issues mentioned in this thread are now tracked in Maplesoft's internal bug-tracking system. Thank you for bring this to our attention. Actually, we just resolved an analogous issue in LimitTutor, also involving csc(x).
This issue is now tracked in Maplesoft's internal bug-tracking system. Thank you for bringing this to our attention.
The issues mentioned in this thread are now tracked in Maplesoft's internal bug-tracking system. (These are embarrassing indeed.) Some problems, like define_external(abort,LIB="/lib64/libc.so.6")(); define_external(abort,WRAPPER,LIB="/lib64/libc.so.6")(); simplify(2.0*eval(normal)); simplify(1.0*eval(eval)); (escaped local) have been resolved, and we are working on resolving the rest of them.
The issues mentioned in this discussion are now tracked in Maple's internal bug-tracking system. Thank you for reporting this problem to us.
The issue mentioned in this post is now tracked in Maple's internal bug-tracking system. While we are fixing this bug, please try the workarounds mentioned above.
Tangent planes are not necessarily horizontal---and a tangent plane that's both horizontal and tangent to the function may not even exist! In fact, for a differentiable function f : R^2 -> R, the only places where the tangent plane is horizontal are saddle points and local extrema of f. The rest of the time, the tangent plane is not horizontal. You can visualize this easily:
plot3d( 1/( 1 + x^2 + y^2 ), x = -1..1, y = -1..1 );
The tangent plane is not horizontal anywhere except at the very top: Everywhere else is "downhill". TRIPLE EDIT: Excellent. OK, so I finally understood the whole conversation. The correct tangent plane is a horizontal one. :)
We have entered this issue into our internal bug-tracker. Thank you for bringing this to our attention.
Just making sure...in case I'm misunderstanding something.
The issues mentioned in this topic have been tracked. This bug is a nasty one.
The issues mentioned in this thread (and various other threads) have been entered into our bug database. We are actually discussing the possibility of adding a "Report a Bug" forum to Mapleprimes; but alas, nothing is final yet.
Page 1 of 1