automatic Inf+NaN*i conversion
Ben Abbott
bpabbott at mac.com
Fri Apr 25 19:23:32 CDT 2008
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
This example doesn't make sense to me A
More information about the Bug-octave
mailing list