automatic Inf+NaN*i conversion

[Ben Abbott]

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