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

>convert(I*cos(x),expsincos); Error, (in convert/expsincos) too many levels of recursion

This problem in slightly modiﬁed form appears in integration of

>int(exp(-I*w*t)/cosh(t),t); Error, (in convert/expsincos) too many levels of recursion

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

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

trace(`convert/expsincos`); convert(I*cos(x),expsincos);

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

> showstat(`convert/expsincos`);

then we see in line 24:

map(`convert/expsincos`,f)

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

type(I,ratpoly(numeric));

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:

> convert(I, expsincos); Error, (in convert/expsincos) too many levels of recursion

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

starts with

if nargs = 1 and type(f,ratpoly(numeric)) then ... elif nargs = 2 and not has(f,x) then ... elif type(f,function) and nops(f) = 1 then ... elif type(f,name) then ... else map(`convert/expsincos`,f) end if

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

> `convert/expsincos`(I):= I;

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

:

> oldconv:= eval(`convert/expsincos`); `convert/expsincos`:= proc(f) if type(f,And(complex,atomic)) then f else oldconv(args) fi end;

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

if nargs = 1 and type(f,ratpoly(numeric)) then f

Change this to

if nargs = 1 and type(f,ratpoly({numeric,complex})) then f

and the function works correct.