bug in convert/expsincos in Maple 6 (8.2.01)

Pavel Honzatko

Does anybody know, why the following occurs in Maple 6.01 and how to fix this.


This problem in slightly modified form appears in integration of


It is corrected with Maple 7. (U. Klein)

Preben Alsholm (12.2.01)

This is no explanation, but just an addition. I tried the following


and I got quite a number of identical statements of the form

enter convert/expsincos, args = I

before my Windows 95 decided to shut down the program.

If we look at the procedure `convert/expsincos` with


then we see in line 24:


When `convert/expsincos` is applied to I*cos(x) the first that happens is that `convert/expsincos` is mapped onto 'I' and cos(x). It is 'I' that is the problematic input to `convert/expsincos` since it is not handled by any other line in the procedure. Thus 'I' will by line 24 be sent to `convert/expsincos`(I) which by its line 24 will send 'I' to etc.....

The 'I' should have been handled by the first line but


returns false in Release 6, but not in Release 5.1.

I suspect that the bug is caused by the change in the handling of complex numbers from Release 5.1 to 6.

Robert Israel (12.2.01)

This is a bad bug, which makes convert(..., expsincos) practically useless on anything containing I. The problem shows up in an even simpler form:


The problem, I think, is that `convert/expsincos` starts with


Since none of the other conditions is true in convert(I,expsincos), the last ”else” clause will run, and `convert/expsincos` will be called recursively. It used to be that I was an alias for (-1)^(1/2), so there would be two recursive calls of `convert/expsincos` with -1 and with 1/2. However, as of Maple 6, I is of type ”complex”, and is considered to be atomic. Thus now `convert/expsincos` is called recursively with the same argument I, and we get an infinite recursion.

At first I thought that a fix was to use the remember table of `convert/expsincos`, with


However, there would still be trouble with every other object of type ”complex”. Instead, I’ll write a ”wrapper” for `convert/expsincos`:


This ought to work.

Werner Knoben (16.2.01)

The reason for the mistake of the function convert/expsincos is that the complex unit I is not any more of type numeric. In the fourth line of the source code of the command `convert/expsincos` you find


Change this to


and the function works correct.