From bug-octave-request at bevo dot che dot wisc dot edu  Wed Sep  6 14:41:20 2000
Subject: real(Inf+Inf*i) vs imag(Inf+Inf*i) asymmetry
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Rolf Fabian <fabian at tu-cottbus dot de>
Cc: "'bug-octave UWISC'" <bug-octave at bevo dot che dot wisc dot edu>
Date: Wed, 6 Sep 2000 14:41:32 -0500 (CDT)

On  6-Sep-2000, Rolf Fabian <fabian at tu-cottbus dot de> wrote:

| Hi,
| 
| For my
| :>version |- 2.1.14 (OS/2)
| installation, I observe the following 'asymmetry' between
| imag(x) and real(x) for no-finite input x.
| 
| I'm afraid that the problem also occurs with current V2.1.31
| 
| ------ IMAG -------
| :1>imag(Inf*i)		|-	Inf	OK
| :2>imag(Inf+Inf*i)	|-	Inf	OK
| :3>imag(Inf)		|-	 0	OK
| 
| ------ REAL -------
| :1>real(Inf)		|-	Inf	OK
| :2>real(Inf+Inf*i)	|-	NaN	<<
| :3>real(Inf*i)		|-	NaN	<<
| 
| In my eyes, the above 'imag' returns are correct,
| whereas the '<<' are erraneous.
| 
| The problem seems NOT to come from 'real'. The underlying
| reason seems to be, that the following assignment
| is automatically converted
| 
| :>x=Inf+Inf*i	|- ans  x=NaN+Inf*i    <<
| 
| to a NaN real part,

I think the bug is that there are no pure imaginary types in Octave,
so I is represented as complex (0, 1) and

  Inf * I  ==  Inf * complex (0, 1)
           ==  complex (Inf * 0, Inf)
           ==  complex (NaN, Inf)

This problem could also be solved by checking every complex
multiplication for zero real part, but that can also lead to
surprising results for someone who is expecting NaN in the case that
the real part of a complex number `accidentally' becomes zero.  It's
not clear to me that this special case is really what you want to have
happen.  A special case for multiplication by 0 is not good for the
real case (I believe that IEEE 754 requires Inf * 0 to return NaN, not
0).

A cleaner way of handling this might be to have a pure imaginary
types.  If the language had only scalar variables, adding it might not
be too bad, but we also have to add pure imaginary vectors, matrices,
etc., along with all the mixed type operations that arise because of
the new type.

Also, surprising results (for those who are expecting NaN if the real
part of a complex happends to become zero) can still happen if
automatic conversion to pure imaginary occurs.

Finally, even with a pure imaginary matrix type and automatic
conversion, do we still need a special case in the real by
complex multiplication for things like

  Inf * [i; 1+i]

since the vector operand is created such that all elements are stored
as complex values.

I think that these details are difficult to get right in an implicitly
typed language like Octave because there isn't one clearly correct
answer and it is hard to guess what the programmer intended.

jwe



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------