7.99 bug in limit-taylor-series, MapleVr5 and Maple 6 (31.5.00)

7.99.1 Ivan Huerta

In the following example limit() fails when x is numeric. Same results with MapleV 5 and Maple 6 on Win98. If x is a variable the results are ok.

> f:= x-> sin(2*Pi*x+Pi/2); 
 
  f := x -> sin(2 Pi x + 1/2 Pi) 
 
> limit( (f(41/100+h)-f(41/100))/h,h=0); 
 
                                   0
 

Curiously enough the series expansion for this expression gives a leading term (-cos(9/50 Pi) + sin(8/25 Pi)) 1/h, but (-cos(9/50 Pi) + sin(8/25 Pi)=0, which fools taylor.

> series( (f(41/100+h)- f(41/100) )/h,h=0); 
 
                                -1                                        2 
(-cos(9/50 Pi) + sin(8/25 Pi)) h   - 2 sin(9/50 Pi) Pi + 2 cos(9/50 Pi) Pi  h 
 
                          3  2                      4  3 
     + 4/3 sin(9/50 Pi) Pi  h  - 2/3 cos(9/50 Pi) Pi  h  - 
 
                        5  4      5 
    4/15 sin(9/50 Pi) Pi  h  + O(h ) 
 
 
> taylor((f(41/100+h)-f(41/100))/h,h=0); 
 
   Error, does not have a taylor expansion, try series() 
 
 
> series((f(x+h)-f(x))/h,h=0); 
 
                                      2                       3  2 
 - 2 sin(2 Pi x) Pi - 2 cos(2 Pi x) Pi  h + 4/3 sin(2 Pi x) Pi  h  + 
 
                      4  3                      5  4      5 
    2/3 cos(2 Pi x) Pi  h  - 4/15 sin(2 Pi x) Pi  h  + O(h ) 
 
> limit((f(x+h)-f(x))/h,h=0); 
 
                       -4 Pi sin(Pi x) cos(Pi x)
 

7.99.2 Robert Israel (5.6.00)

Well, I think you provided the clue yourself: "limit" looks at what it thinks is the leading term of a series expansion. It’s not so obvious why, if Maple thinks there’s a 1/h term in the series, it comes up with 0 rather than +infinity or -infinity or undefined: I think that’s because it looks at the signum of the coefficient of the leading term in order to decide which of these to return, and "signum" is clever enough to know that -cos(9/50 Pi) + sin(8/25 Pi)=0.

The way that series tests whether something is zero is specified in the environment variable Testzero, which is usually set to just use "normal". In this case it will work better if you use "is" instead:

> restart; 
  Testzero:= proc(x) is(x,0) end; 
  f := x -> sin(2*Pi*x + Pi/2); 
  limit( (f(41/100+h)-f(41/100))/h,h=0); 
 
       -2 sin(9/50 Pi) Pi
 

7.99.3 Helmut Kahovec (6.6.00)

That is an interesting bug. As I found out by using the Maple debugger, this bug seems to be unavoidable if the procedure limit() and the procedures called by it cannot determine whether a trig expression is zero or not. Look at the following short Maple session:

> restart; 
> expr:=x+(-cos(9/50*Pi)+sin(8/25*Pi))/h; 
 
                           -cos(9/50 Pi) + sin(8/25 Pi) 
               expr := x + ---------------------------- 
                                        h 
 
> limit(expr,h=0); 
 
                                  0
 

This is certainly wrong as the result should be x. The procedure limit() cannot verify that -cos(9/50 Pi) + sin(8/25 Pi) equals zero. However, testeq() can:

> zero_trig_expr:=-cos(9/50*Pi)+sin(8/25*Pi); 
 
            zero_trig_expr := -cos(9/50 Pi) + sin(8/25 Pi) 
 
> testeq(zero_trig_expr=0); 
 
                                 true
 

Thus, as a first bugfix, limit() and the procedures called by it should make use of testeq(), too.