3.1 0.i in maple 6 (17.10.00)

3.1.1 Theodore Kolokolnikov (23.10.01)

> 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 differently than reals; but still...

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

3.1.2 Andrzej Pindor (19.10.00)

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.
 

3.1.3 David Harrington (19.10.00)

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 affected by fnormal. Use simplify(expr, zero) to remove 0 real or imaginary parts of complex floating point numbers."