[Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)

[tim_one@email.msn.com]

[Guido]
> OK, so let's stick with the defaults that 754 presecribes until we can
> give the user control.  That's the purpose of defaults, right?

In every world other 754 (see below), but we really have no choice now
(because C doesn't give us any control now).

> I think even 754 tells us that 1e-500 is smaller than what we normally
> need to deal with.

Well, there is no 1e-500 under 754, which is why there's some reason to at
least warn about it (if the user wanted 0, why didn't they type 0?).

> Again: 754 gives a default.  I want to conform to the default -- it's
> better to provide control, but even when we provide control, there will
> still be default behavior, and (if I understand 754 correctly) the
> default is not to interrupt for underflow.

The 754 default is never to raise an exception no matter what, whether
overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0.  So
Python's current behavior wrt these two is non-conforming:

    math.sqrt(-4)
    1. / 0.

However, 754 is primarily a HW std, and the defaults were prescribed by a
committee of HW geeks and math library authors.  They were caught totally
off guard by how long it took for languages to provide the control features
the std also mandates -- for "regular users" it's plainly insane to avoid
griping about the two above, and it was never 754's intent to let them pass
silently for regular users.

Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for
accepting the defaults but not providing the also-mandated control
functions.  The std is subtler than it appears, and all the fiddly bits are
really needed.

>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>> >>> 1e500
>> 1.#INF
>> >>> 1e200**2
>> 1.#INF
>> >>>

> Oops, you're right.  Must be another 754 default behavior!

Right.

> I would personally also prefer an exception for overflow.  You don't
> say what you want for underflow though.  I still like silent underflow
> to zero by default.

754 defines (almost) everything:  underflow when the underflow exception is
masked out must deliver a zero with the same sign as the infinite-precision
result.

> I'm not fighting it.

You will <wink>; e.g., returning 1 for "x == x" is incorrect when x is a
NaN.

> Say the ideal Python has full user control over fp exceptions.  What
> should the defaults be?

IMO, exception on overflow, divide-by-0 and invalid operation.  Let
underflow and inexact pass silently.  That's what I implemented at KSR, and
customers were *very* much happier with that than with the 754 defaults.  Of
course I also implemented all the 754 control and status inquiry functions,
so the one 754-savvy programmer per site was happy too (they need the
control to write robust numerical libraries for everyone else to use -- the
*true* purpose of the 754 HW defaults).

> Python 1.6 should have the same defaults, even if it doesn't have the
> controls.

This is a big project, as there's no portable way even to detect fp overflow
now.  The math libraries should play along too.

> I'll change float() to use atof().

OK by me!