automatic Inf+NaN*i conversion

[Jaroslav Hajek]

On Sat, Apr 26, 2008 at 2:23 AM, Ben Abbott <bpabbott at mac.com> wrote:
>
>
>  On Apr 25, 2008, at 7:11 PM, John W. Eaton wrote:
>
>
> > On 25-Apr-2008, Ben Abbott wrote:
> >
> > | On Apr 25, 2008, at 12:42 PM, Jaroslav Hajek wrote:
> > |
> > | > No, you are just plain wrong. As you have seen earlier, Inf+NaN*i
> > | > does not give
> > | > complex(Inf, NaN), but rather complex(NaN, NaN), due to the fact that
> > | > it is calculated as
> > | > complex(Inf + 0*NaN, 0 + 1*NaN). The behaviour of isinf is OK - it
> > | > gives infinity if either part of the complex number is Inf.
> > |
> > | I thought I understood your point, but when I tested myself, the test
> > | did not meet my expectation :-(
> > |
> > | Specifically, It appears to me that the two examples below are in
> > | contradiction.
> > |
> > | octave:45> NaN*(1+0i) + Inf*(0+1i)
> > | ans = NaN + Infi
> > | octave:46> NaN*complex(1,0) + Inf*complex(0,1)
> > | ans = NaN - NaNi
> > |
> > | What is happening in this instance?
> >
> > Break it down into the components and look at each of them
> > separately.  Note that 1+0i is 1 (i.e. not a complex value).  Although
> > it looks like you are writing a complex number when you write 1+0i,
> > you are really writing an addition expression, and 0i is automatically
> > converted to 0, so you are really writing 1+0.  However, the result of
> > complex(0,1) isn't automatically converted to real, so it does allow
> > you to create complex values with zero imaginary components.
> >
> > Yes, NaN*complex(1,0) --> NaN - NaNi looks "wrong", but does the sign
> > really matter here?  I mean, it's a NaN.  In any case, Jaroslav's
> > patch is probably a reasonable thing to do (I haven't had a chance to
> > try it yet).
> >
> > jwe
> >
>
>  My thought is that NaN should trump Inf ... or Inf should trump a NaN.
>
>  octave:57> NaN+1i*Inf
>  ans = NaN + Infi
>  octave:58> Inf+1i*NaN
>  ans = NaN - NaNi
>  octave:59>
>
>  Although this behavior may be explained by examining the underlying
> algorithm. Is the function of the algorithm sensible or proper?
>
>  Should not both examples give consistent results? ... by consistent I mean
> that neither the real-part or the imag-part should be favored.
>
>  ... or am I missing something?
>
>  Ben
>
You just have to keep in mind that a+b*i is not a means of writing a
constant in Octave (neither in Matlab), but rather a calculation. Inf
is a real number, NaN is a real number, i is a complex number. After
that, the whole matter becomes crystal clear.

Further, I think that there is no IEEE standard on complex number
arithmetic, so what NaN-ish and Inf-ish complex calculations should
return is a matter for discussion. Personally, I'd tend to regard the
C99 standard, Informal annex G (or some other letter, I'm not sure) as
a reasonable authority, given that Octave is written in C++. I don't
think C++98 standard addresses this anywhere, but the next standard
probably will (or will reference the C99 standard).


-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz