> 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
> 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.”