7.90 bug in integration in Maple 6 (11.6.01)

7.90.1 Liu Yuting

> int(log(sin(t)), t=0..Pi);
 

Maple 6 gives 0 (wrong).

> int(log(sin(x)), x=0..Pi);
 

Maple 6 gives -Pi*ln(2) (correct).

It seems that only ’x’ works. Would anyone like to fix it?

7.90.2 Jason Schattman (15.6.01)

This bug has been fixed in Maple 7. Both of the problems given below output -Pi*ln(2).

7.90.3 Helmut Kahovec (16.6.01)

On Wed, 16 May 2001 at 12:05:34 GMT I wrote in comp.soft-sys.math.maple (answering the same question):

The bug is in the global table `int/itable`, which is used in a table lookup at line 2 of `int/indef1`(). There is a typo in the entries for ln(cos(_X)) and ln(sin(_X)) where an x appears instead of an _X:

> eval(`int/itable`[ln(cos(_X))]); 
 
                                                            2 
         1/2 I polylog(2, -exp(2 I _X)) - x ln(2) - 1/2 I _X 
                                          ^ 
 
> eval(`int/itable`[ln(sin(_X))]); 
 
                                                                  2 
   -1/2 I polylog(2, exp(-2 I _X)) - x ln(2) + 1/2 I (1/2 Pi - _X) 
                                     ^
 

I am quite sure that the people at Maplesoft already know this bug.

In order to fix this bug we only have to modify those two entries:

> restart; 
 
> `int/itable`[ln(cos(_X))]:= 
>   1/2*I*polylog(2,-exp(2*I*_X))-_X*ln(2)-1/2*I*_X^2: 
                                  ^^ 
__________________________________|| 
 
> `int/itable`[ln(sin(_X))]:= 
>   -1/2*I*polylog(2,exp(-2*I*_X))-_X*ln(2)+1/2*I*(1/2*Pi-_X)^2: 
                                   ^^ 
___________________________________||
 

Now we get in turn:

> int(log(sin(t)),t=0..Pi); 
 
                              -Pi ln(2) 
 
> int(log(sin(x)),x=0..Pi); 
 
                              -Pi ln(2) 
 
> int(log(cos(t)),t=-Pi/2..Pi/2); 
 
                              -Pi ln(2) 
 
> int(log(cos(x)),x=-Pi/2..Pi/2); 
 
                              -Pi ln(2)
 

7.90.4 Carl DeVore (19.6.01)

This integral is done as a simple table lookup. Someone typed x instead of _X into the table. To fix it:

> `int/itable`:= subs(x= _X, eval(`int/itable`));
 

This brings up a more general and severe point. There needs to be a more mechanized way of checking these things, of finding these bugs. This is essential if Maple is ever going to be used for some critical, real-time, life-or-death application – for example, traffic control. If you misspell a variable name in Maple, that error is not detected. It just assumes that you mean some other undefined "name". There should be an option that produces a warning whenever the parser detects an undeclared name; and, of course, to match that, there should be a way to declare names other than procedure parameters.

7.90.5 Humberto Jose Bortolossi (22.6.01)

What about a free patch for Maple 6.x owners? Always we have to upgrade (and pay more money) to get bugs fixed???

7.90.6 Robert Israel (22.6.01)

Carl DeVore wrote: This brings up a more general and severe point. ...

I really hope nobody ever uses Maple for critical, life-or-death applications. It’s much too complicated to ever be sure that there are no more bugs, even if much more effort was put into searching for and correcting them. That type of application needs a much different style of programming.

Sufficiently complicated software may be impossible to certify as bug-free anyway - cf. the debate some years ago in connection with the "Star Wars" missile defence system.

Sun’s Java Development Kit comes with a disclaimer:

Software is not designed or intended for use in on-line control of aircraft, air traffic, aircraft navigation or aircraft communications; or in the design, construction, operation or maintenance of any nuclear facility. Licensee warrants that it will not use or redistribute the Software for such purposes.

Maybe Maple should too.

7.90.7 Joe Riel (home) (27.6.01)

Carl DeVore wrote: If you misspell a variable name in Maple, ...

The solution is to use mint, it detects unused and undeclared variables.