PEP 238 (revised)

[Bengt Richter]

Update: Scheme's 'wart' was a beauty spot after all ;-)

On Sat, 28 Jul 2001 04:51:08 GMT, bokr at accessone.com (Bengt Richter) wrote:

>On Fri, 27 Jul 2001 19:59:16 GMT, Guido van Rossum <guido at python.org> wrote:
>[...]
>>
>>IEEE 754, the floating point standard in use in virtually all current
>>hardware, mandates that -0.0 be distinguishable from 0.0, in order to
>>be able to represent the sign of degenerated underflow results.  (Or
>>so I understand, having been educated in IEEE 754 through numerous
>>discussions with Tim Peters, but not by reading the standard.  If I'm
>>wrong, Tim will surely correct me. :-)
>>
>>I don't know of a portable way to generate -0.0 in Python; on my Linux
>>box, simply writing -0.0 does it, but not on my Windows box.
>>
>My gut feeling is that the symmetry of sign,magnitude numbers in IEEE754 is not good
>when you are dealing with a mapping of the real axis to the unit circle. It doesn't
>feel right to me, though probably it's not of much practical consequence.
>
I still feel that way ;-)

>But, speaking of the unit circle, UIAM Scheme has what appears to me to be a wart.
>Functions that return angles apparently do so as values in (-pi,pi] rather than
>[-pi,pi). To me that is a wart. Apparently Scheme got it from APL, and I still haven't
>got to the local U library to see the referenced paper with the rationale. Mathematically,
>you can't translate the interval by exactly pi and get a 2pi interval that includes zero!
>It strikes me as weird to exclude zero and include 2pi. [1]
Well, it's also weird to translate that interval by pi ;-/ I wasn't looking at what it really
means. I.e., the interval (-pi,pi] is really effectively two intervals, (-pi,0) and [0,pi],
which you can separate out from (-pi,pi] and rearrange with the ususal

    if angle < 0: angle += twopi

getting [0,pi],(pi,2pi) with the pi's merging for [0,2pi) as I wanted.

I've programmed that a zillion times. I just wasn't looking at (-pi,pi] in terms of the
two intervals :-/


But I think the real truth is that IEEE754 returns [-pi,-0][0,pi].
"if angle < 0" can separate that into [-pi,-0) and [-0][0,pi] and then
adding 2pi to [-pi,-0) gives [pi,2pi) to combine with [-0][0,pi] for [-0][0,2pi).

The -0 will probably disappear benignly at some point if ignored,
but I wonder if the function is relying on that always happening
in the caller's code.

You can ignore the following paragraph, after the intervals have been fixed as above ;-/
>
>And look what that interval does if you want to turn it into a Python index range
>for k steps of 2*pi/k. Adding pi to an angle puts it in (0,2pi] -- and unless you
>turn 2pi into zero before doing angle*k//twopi, you will have an out of range index
>when an arctangent returns pi instead of -pi.
>
I wonder if (angle*k//twopi)<k is always true if angle<twopi. Seems like
it should be for positive numbers anyway.

>My intel book says the pentium FPATAN instruction returns radians with a magnitude
>*less than* pi, so whatever constant is defined as pi for purposes of returning it
>from software, the choice must have been made there between +pi and -pi, or they just
>return whatever the hardware provides, which would make the scheme documentation wrong
>about the interval. It could either be called (-pi,pi) or [-pi,pi], but not half open.
>
Well, looking in another part of the book, it uses the pi symbol and says inclusive as
well as specifying the signed zero cases. So I conclude [-pi,-0][0,pi] is coming from the
hardware. Which is not half open until splitting off and translating the negative piece
by 2pi, as above.

>Is this something that might be given a clean resolution in Python?
>I.e., [-pi,pi) , IMHO ;-)
>
Never mind, Scheme's interval is fine (just that it's really two for some purposes).
I can make what I wanted after all *<8-p

I wonder if Scheme actually returns the hardware result or forces -pi to +pi specially
to make (-pi,pi] their actual result range per their spec.

I'll post this before looking. ;-)