#### 3.1 0.i in maple 6 (17.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."