3.1.1 Theodore Kolokolnikov (23.10.01)

3.1.2 Andrzej Pindor (19.10.00)

3.1.3 David Harrington (19.10.00)

3.1.2 Andrzej Pindor (19.10.00)

3.1.3 David Harrington (19.10.00)

> evalf(0.*I); 0. I

It would be better if Maple would produce `"0."`

instead.

I mean, I know that Maple now treats complex numbers diﬀerently than reals; but still...

> evalb(0.*I=0.); true

This is another bizzare consequence of the new way chosen to represent complex numbers. Note that:

|\^/| Maple 6 (SUN SPARC SOLARIS) ._|\| |/|_. Copyright (c) 2000 by Waterloo Maple Inc. \ MAPLE / All rights reserved. Maple is a registered trademark of <____ ____> Waterloo Maple Inc. | Type ? for help. > op(0.*I); 0. > whattype(0.*I); complex

To retain the complex type Maple insist on keeping "I" in the expression. Interestingly

> op(2+3*I); 2, 3 > op(0+3*I); 3

Would it be not more consistent if the result of `op(0+3*I)`

was `0,3`

? In particular,
that

> op(0. + 0.*I); 0., 0. > op(0.+0*I); 0, 0

Why then:

> op(0+0*I); 0 > op(0+0.*I); 0.

The help under fnormal suggests that this is deliberate, and gives a remedy:

"fnormal preserves numeric type and sign information as much as possible. Thus, for
example, `fnormal(1e-20*I, 10) = 0.*I`

not `0.`

. This ensures that branching behaviour is
generally not aﬀected by fnormal. Use simplify(expr, zero) to remove 0 real or imaginary
parts of complex ﬂoating point numbers."