Tim Peters wrote:
> [Steven D'Aprano]
>>It isn't necessary to look at complex numbers to see the difference
>>between positive and negative zero. Just look at a graph of y=1/x. In
>>particular, look at the behaviour of the graph around x=0. Now tell me
>>that the sign of zero doesn't make a difference.
>
>
> OK, I looked, and it made no difference to me. Really. If I had an
> infinitely tall monitor, maybe I could see a difference, but I don't
> -- the sign of 0 on the nose makes no difference to the behavior of
> 1/x for any x other than 0. On my finite monitor, I see it looks like
> the line x=0 is an asymptote, and the graph approaches minus infinity
> on that line from the left and positive infinity from the right; the
> value of 1/0 doesn't matter to that.
Well, I didn't say that the value of zero made a
difference for _other_ values of x. Perhaps you and I
are interpreting the same graph differently. To me, the
behaviour of 1/x around x = 0 illustrates why +0 and -0
are different, but it isn't worth arguing about.
>>Signed zeroes also preserve 1/(1/x) == x for all x,
>
>
> No, signed zeros "preverse" that identity for exactly the set {+Inf,
> -Inf}, and that's all.
Preverse? Did you mean "pervert"? Or just a mispelt
"preserve"? Sorry, not trying to be a spelling Nazi, I
genuinely don't understand what you are trying to get
across here.
> That's worth something, but 1/(1/x) == x isn't
> generally true in 754 anyway.
Of course it isn't. Sorry, I was thinking like a
mathematician instead of a programmer again.
(Note to self: write out 1000 lines, "Real number !=
floating point number".)
[snip]
>>>Odd bit o' trivia: following "the rules" for signed zeroes in 754
>>>makes exponeniation c**n ambiguous, where c is a complex number with
>>>c.real == c.imag == 0.0 (but the zeroes may be signed), and n is a
>>>positive integer. The signs on the zeroes coming out can depend on
>>>the exact order in which multiplications are performed, because the
>>>underlying multiplication isn't associative despite that it's exact.
>>
>
>>That's an implementation failure. Mathematically, the sign of 0**n should
>>depend only on whether n is odd or even. If c**n is ambiguous, then that's
>>a bug in the implementation, not the standard.
>
>
> As I said, these are complex zeroes, not real zeroes. The 754
> standard doesn't say anything about complex numbers. In rectangular
> form, a complex zero contains two real zeroes. There are 4
> possiblities for a complex zero if the components are 754
> floats/doubles:
>
> +0+0i
> +0-0i
> -0+0i
> -0-0i
>
> Implement Cartesian complex multiplication in the obvious way:
>
> (a+bi)(c+di) = (ac-bd) + (ad+bc)i
Yes, but that supports what I said: it is an
_implementation_ issue. A different implementation
might recognise a complex zero and return the correctly
signed complex zero without actually doing the
multiplication.
Assuming mathematicians can decide on which complex
zero is the correct one.
> Now use that to raise the four complex zeroes above to various integer
> powers, trying different ways of grouping the multiplications. For
> example, x**4 can be computed as
>
> ((xx)x)x
>
> or
>
> (xx)(xx)
>
> or
>
> x((xx)x)
>
> etc. You'll discover that, in some cases, for fixed x and n, the
> signs of the zeroes in the result depend how the multiplications were
> grouped. The 754 standard says nothing about any of this, _except_
> for the results of multiplying and adding 754 zeroes. Multiplication
> of signed zeroes in 754 is associative. The problem is that the
> extension to Cartesian complex multiplication isn't associative under
> these rules in some all-zero cases, mostly because the sum of two
> signed zeroes is (under 3 of the rounding modes) +0 unless both
> addends are -0. Try examples and you'll discover this for yourself.
Yes, point taken. But that is just another example of
where floats fail to be sufficiently close to real
numbers. In a "perfect" representation, this would not
be a factor.
However... now that I think of it... in polar form,
there are an uncountably infinite number of complex zeroes.
z = 0*cis(0), z = 0*cis(0.1), z = 0*cis(-0.21), ...
I think I won't touch that one with a fifty foot pole.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
