[ruby-core:24193] Re: [Bug #1715] Numeric#arg for NaN is Inconsistent Across Versions

On 7/5/2009 12:28 PM, tadayoshi funaba wrote:
>>> If we want to be precise in the Unknown, maybe both versions should give 
>>> NaN for 0.arg and 0.0.arg (and Complex zero) as well?
> 
> no.
> 
>> but returns:
>> Complex(NaN,NaN)
> 
> i hope not.

What is it that you don’t hope? That Complex.polar(0.0,0/0.0) returns Complex(NaN,NaN), or that I think that this is wrong?


> complex try to preserve flonum status.

Which is completely nonsense. Since there is no _correct_ positive flonum status for +0.0 (as it is mixed with precise 0), there is really little use 
in -0.0, and it should not be used as an entry point for further calculations. Zero is zero and never the approximation, even if floats allow that as 
a result of a calculation to give a hint in very special situations.

> Complex(-0.0, 0.0).polar #=> [0.0, 3.141592653589793]
> Complex(0.0, -0.0).polar #=> [0.0, -0.0]
> Complex(-0.0, -0.0).polar #=> [0.0, -3.141592653589793]

That’s completely senseless: If you say Complex(-0.0, -0.0), you approach zero very explicitly from -135 degrees, why should it be -180 degrees then? 
Assuming approaching behavior for -0.0 and 0.0, all argument values would have to be something like PI/4 +- n*PI/2, so zero-length arrows in +-45 
degrees and +-135 degrees then.

> Complex.polar(0.0, 3.141592653589793) #=> (-0.0+0.0i)
> Complex.polar(0.0, -0.0) #=> (0.0-0.0i)
> Complex.polar(0.0, -3.141592653589793) #=> (-0.0-0.0i)

The problem with this useless precision in the approaching range around zero is that you _have_ to make Complex.polar(0.0, 0/0.0) equal to 
Complex(NaN, NaN), just because you cannot decide between -0.0 and +0.0, especially their various combinations in the complex layer! Really senseless, 
sorry, it should be zero as it is, and zero is 0.0 (vice versa).

Just to repeat myself: The difference between +0 and -0 is very esoteric and incompletely implemented in IEEE 754, as there is no explicit precise 0 
if you want to use 0.0 as +0.0 and -0.0 as its negative. The use of -0 is not advised in general calculation but in very special situations, 
especially hard to apply to the complex numbers. In fact, whenever 0.0 is used, instead of assuming it to mean +0.0, it is precisely zero, except for 
the cases specified in IEEE 754 to get positive or negative Infinity. Clearly, the argument of 0 is NaN, and polar should equally know how to handle 
NaN arguments for a 0.0 distance.

Similarly, if you invert 0.0, you should get NaN because you cannot decide between +Infinity or -Infinity. In addition to the missing precise zero (Q: 
is it missing at all?), IEEE 754 should define a unknown Infinity, something that could be either positive or negative.

> anyway, complex respects flonum's rules.

For no practical reason except underflow and infinity handling which are special cases anyway.

Other examples where standard formulae don’t help much:

a=Complex(1/0.0,3)
b=Complex(1/0.0,-5)

p a*a      # => Complex(Infinity, Infinity), expected: Complex(Infinity, 0.0)
p a*b      # => Complex(Infinity, NaN), expected: Complex(Infinity, 0.0)
p a/b      # => Complex(NaN, NaN), expected: Complex(NaN, 0.0)

here, you will see that the imaginary part approaches zero quicker than the real part, so while the latter two examples are at least covered in the 
result given by ruby, the first is clearly wrong.

– Matthias