automatic Inf+NaN*i conversion

[Jaroslav Hajek]

On Sat, Apr 26, 2008 at 8:39 PM, Ben Abbott <bpabbott at mac.com> wrote:
>
>
>  On Apr 26, 2008, at 2:19 PM, Jaroslav Hajek wrote:
>
>
> > 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.
> >
> >
>
>  To be honest, given those three example, it appears to me that everything
> is working as it should.
>
Except for the minus sign in NaN, and I've submitted the fix. And I'm
not even sure the bug is in Octave - Octave generates NaN by first
generating +Inf and doing +Inf/+Inf. IMHO this should produce +NaN if
NaN is signed, but I'm not sure, and I'm also not sure whether the
ability to set sign bit for NaN is the same thing as having signed
NaN.
It's hard to say whether the bug can be in GCC - could divison be
compiled in some other way than a FP divide instruction? Perhaps this
is not a real bug after all, but it seemed reasonable to me having the
positive NaN as the default, hence the fix.

>  While this discussion is getting a bit moot, what of this example?
>
>  octave:15> Inf*Inf
>  ans = Inf
>  octave:16> complex(Inf,Inf)*complex(Inf,Inf)
>  ans = NaN + Infi
>
>  Should not Inf*Inf = NaN? ... I'm not informed regarding the IEEE standards
> for such :-(
>

No, Inf*Inf should definitely be Inf. That's the most useful behaviour.

>  Ben
>
>



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