pickle broken: can't handle NaN or Infinity under win32

Steven D'Aprano steve at REMOVEMEcyber.com.au
Thu Jun 23 23:40:33 EDT 2005


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.




More information about the Python-list mailing list