Does anybody know, why the following occurs in Maple 6.01 and how to ﬁx this.
This problem in slightly modiﬁed form appears in integration of
It is corrected with Maple 7. (U. Klein)
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 ﬁrst 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 ﬁrst 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.
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 inﬁnite recursion.
At ﬁrst I thought that a ﬁx 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.
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 ﬁnd
Change this to
and the function works correct.