PEP0238 lament

Tim Hochberg tim.hochberg at ieee.org
Mon Jul 23 20:20:36 CEST 2001


"Tim Peters" <tim at digicool.com> wrote in message
news:mailman.995908060.25272.python-list at python.org...
> [Tim Hochberg]
[SNIP]
> > This is correct, but can hardly be called simple or clear.
>
> In this specific case "x + 0.0" is correct, but in general it isn't:  on
> boxes with 754 arithmetic (virtually everything), x+0. has a different
sign
> bit than x when x is -0.0, and the default rounding mode is in effect.  In
> this specific case that doesn't matter because the result is immediately
> squared, but in general you can't know that it doesn't matter.  Safest is
>
>     x*1.0
>
> which works in all cases -- maybe.  There's still hardware out there that
> flushes denormal results to 0, and on such boxes both x+0. and x*1.0 can
> return 0 when x is not 0.  Python inherits such behaviors from the
platform.
>
> So "this is more difficult than generally supposed" applies even to people
> who know quite a bit about this stuff.

Hey! You clipped my disclaimer...

Anyway, there's another worry when working with NumPy is that both my
solution (which is really Konrad's, so I'll blame it on him) and the correct
one above may quietly convert some huge array (x) of C floats into an array
of C doubles and bring your machine to its knees. Unless you make sure the
save-space flag is set, but that checking that adds a whole 'nother layer of
cruft. Or you could multiply by a rank zero array of type 'f', but that has
some doesn't really do the right thing either. Doing this so that works
right for arrays in the general case is big mess. Fortunately for me, I
always use doubles....

And when I want to sleep poorly at night, I go read one of Kahan's papers as
per Tim Peter's recomendation.


-the-only-thing-that-helps-is-changing-accuracy-and-hoping-for-the-same-answ
er-ly yours,
-tim





More information about the Python-list mailing list