On 6/4/11 4:28 PM, Ethan Furman wrote:
Steven D'Aprano wrote:
On Fri, 03 Jun 2011 23:04:38 -0700, Ethan Furman wrote:
Steven D'Aprano wrote:
NANs are not necessarily errors, they're hardly silent, and if you
don't want NANs, the standard mandates that there be a way to turn them
off.
So how does one turn them off in standard Python?
Turn them off? You have to find a way to turn them on first! What makes you
think that Python supports IEEE-754 for floats?
So if Python doesn't support IEEE-754 for floats, why the big deal about NaNs?
Steven is being a little hyperbolic. Python does not fully conform to all of the
details of the IEEE-754 specification, though it does conform to most of them.
In particular, it raises an exception when you divide by 0.0 when the IEEE-754
specification states that you ought to issue the "divide by zero" or "invalid"
signal depending on the numerator (and which may be trapped by the user, but not
by default) and will return either an inf or a NaN value if not trapped. Thus,
the canonical example of a NaN-returning operation in fully-conforming IEEE-754
arithmetic, 0.0/0.0, raises an exception in Python. You can generate a NaN by
other means, namely dividing inf/inf.
One other deviation is the one which you were asking about. The standard does
say that the "invalid" signal should be issued in most circumstances that
generate a NaN and that the user should be able to trap that signal. Python
explicitly disables that mechanism. It used to provide an optional module,
fpectl, for providing a signal handler for those. However, creating a handler
for such a low-level signal in a high-level language like Python is inherently
unsafe, so it is not really supported any more.
The decimal module mostly gets it right. It translates the signals into Python
exceptions that can be disabled in a particular context.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
