automatic Inf+NaN*i conversion

[Jaroslav Hajek]

On Sat, Apr 26, 2008 at 4:47 PM, Ben Abbott <bpabbott at mac.com> wrote:
>
>
>  On Apr 26, 2008, at 12:41 AM, Jaroslav Hajek wrote:
>
>
> > 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).
> >
>
>  So this boils down to
>
>  octave:1> NaN+Inf
>  ans = NaN
>  octave:2> 0*NaN
>  ans = NaN
>  octave:3> 0*Inf
>  ans = NaN
>
>  Correct?
>
>  Ben
>

Exactly. For constructing complex numbers without such side-effects,
use the `complex' function.





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