Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Why does python break IEEE 754 for 1.0/0.0 and 0.0/0.0?

Reply
Thread Tools

Why does python break IEEE 754 for 1.0/0.0 and 0.0/0.0?

 
 
Grant Edwards
Guest
Posts: n/a
 
      07-14-2005
I've read over and over that Python leaves floating point
issues up to the underlying platform.

This seems to be largely true, but not always. My underlying
platform (IA32 Linux) correctly handles 1.0/0.0 and 0.0/0.0
according to the IEEE 754 standard, but Python goes out of its
way to do the wrong thing.

1/0 is defined by the standard as +Inf and 0/0 is NaN.

That's what my platform does for programs written in C. Python
apparently checks for division by zero and throws and exception
rather than returning the correct value calculated by the
underlying platform.

Is there any way to get Python to return the correct results
for those operations rather than raising an exception?

There's no way to "resume" from the exception and return a
value from an exception handler, right? [This is the other
option allowed by the IEEE 754 standard.]

--
Grant Edwards grante Yow! ... I want a COLOR
at T.V. and a VIBRATING BED!!!
visi.com
 
Reply With Quote
 
 
 
 
Tim Peters
Guest
Posts: n/a
 
      07-14-2005
[Grant Edwards]
> I've read over and over that Python leaves floating point
> issues up to the underlying platform.
>
> This seems to be largely true, but not always. My underlying
> platform (IA32 Linux) correctly handles 1.0/0.0 and 0.0/0.0
> according to the IEEE 754 standard, but Python goes out of its
> way to do the wrong thing.


Python does go out of its way to raise ZeroDivisionError when dividing by 0..

> 1/0 is defined by the standard as +Inf and 0/0 is NaN.
>
> That's what my platform does for programs written in C.


IOW, that's what your platform C does (the behavior of these cases is
left undefined by the C89 standard, so it's not the case that you can
write a _portable_ C89 program relying on these outcomes). What does
your platform C return for the integer expression 42/0? Is any other
outcome "wrong"?

> Python apparently checks for division by zero and throws and exception
> rather than returning the correct value calculated by the
> underlying platform.
>
> Is there any way to get Python to return the correct results
> for those operations rather than raising an exception?


No, except when using the decimal module. The latter provides all the
facilities in IBM's proposed standard for decimal floating-point,
which intends to be a superset of IEEE 854:

http://www2.hursley.ibm.com/decimal/

It's relatively easy to do this in the decimal module because it
emulates, in software, all the gimmicks that most modern FPUs provide
in hardware.

Note that support for 754 was rare on Python platforms at the time
Python was designed, and nobody mentioned 754 support as even a vague
desire in those days. In the absence of user interest, and in the
absence of HW support for NaNs or infinities on most Python platforms,
the decision to raise an exception was quite sensible at the time.
Python could not have implemented 754 semantics without doing
emulating fp arithmetic in SW on most platforms (as the decimal module
does today), and for much the same reasons you can't give a non-silly
answer to my earlier "what does your platform C return for the integer
expression 42/0?" question today <wink>.

> There's no way to "resume" from the exception and return a
> value from an exception handler, right?


Correct.

Note that there's a huge, current, informed discussion of these issues
already in the math.nroot thread.
 
Reply With Quote
 
 
 
 
Grant Edwards
Guest
Posts: n/a
 
      07-14-2005
On 2005-07-14, Tim Peters <(E-Mail Removed)> wrote:

> Python does go out of its way to raise ZeroDivisionError when
> dividing by 0.
>
>> 1/0 is defined by the standard as +Inf and 0/0 is NaN.
>>
>> That's what my platform does for programs written in C.

>
> IOW, that's what your platform C does (the behavior of these
> cases is left undefined by the C89 standard, so it's not the
> case that you can write a _portable_ C89 program relying on
> these outcomes).


True, but as a paracial matter, all of the C platforms I care
about all do obey IEEE 754.

> What does your platform C return for the integer expression
> 42/0? Is any other outcome "wrong"?


I guess I though it was obvious from my reference to IEEE 754
that I was referring to floating point operations. I don't
know (or generally care) what my C platform does for integer
divide by zero.

>> Python apparently checks for division by zero and throws and
>> exception rather than returning the correct value calculated
>> by the underlying platform.
>>
>> Is there any way to get Python to return the correct results
>> for those operations rather than raising an exception?

>
> No, except when using the decimal module. The latter provides
> all the facilities in IBM's proposed standard for decimal
> floating-point, which intends to be a superset of IEEE 854:
>
> http://www2.hursley.ibm.com/decimal/
>
> It's relatively easy to do this in the decimal module because
> it emulates, in software, all the gimmicks that most modern
> FPUs provide in hardware.
>
> Note that support for 754 was rare on Python platforms at the
> time Python was designed, and nobody mentioned 754 support as
> even a vague desire in those days.


I often foget how old Python is. Still, I've been using IEEE
floating point in C programs (and depending on the proper
production and handling of infinities and NaNs) for more than
20 years now. I had thought that Python might have caught up.

> In the absence of user interest, and in the absence of HW
> support for NaNs or infinities on most Python platforms,


Really? I would have guessed that most Python platforms are
'586 or better IA32 machines running either Windows or Linux.
They all have HW support for NaNs and Infinities.

> the decision to raise an exception was quite sensible at the
> time. Python could not have implemented 754 semantics without
> doing emulating fp arithmetic in SW on most platforms (as the
> decimal module does today), and for much the same reasons you
> can't give a non-silly answer to my earlier "what does your
> platform C return for the integer expression 42/0?" question
> today <wink>.
>
>> There's no way to "resume" from the exception and return a
>> value from an exception handler, right?

>
> Correct.
>
> Note that there's a huge, current, informed discussion of
> these issues already in the math.nroot thread.


--
Grant Edwards grante Yow! It's OKAY --- I'm an
at INTELLECTUAL, too.
visi.com
 
Reply With Quote
 
Tim Peters
Guest
Posts: n/a
 
      07-14-2005
[Tim Peters]
....
>> What does your platform C return for the integer expression
>> 42/0? Is any other outcome "wrong"?


[Grant Edwards]
> I guess I though it was obvious from my reference to IEEE 754
> that I was referring to floating point operations.


Yes, that was obvious. Since I thought my point would be equally
obvious, I won't spell it out <0.7 wink>.

....

>> Note that support for 754 was rare on Python platforms at the
>> time Python was designed, and nobody mentioned 754 support as
>> even a vague desire in those days.


> I often foget how old Python is. Still, I've been using IEEE
> floating point in C programs (and depending on the proper
> production and handling of infinities and NaNs) for more than
> 20 years now. I had thought that Python might have caught up.


It has not. Please see the other thread I mentioned.

>> In the absence of user interest, and in the absence of HW
>> support for NaNs or infinities on most Python platforms,


> Really?


Yes, but looks like you didn't finish reading the sentence. Here's
the rest, with emphasis added:

>> the decision to raise an exception was quite sensible AT THE TIME.


You may have forgotten how much richer the "plausible HW" landscape
was at the time too. I was deeply involved in implementing Kendall
Square Research's HW and SW 754 story at the time, and it was all
quite novel, with little prior art to draw on to help resolve the
myriad language issues 754 didn't address (e.g., what should Fortran's
3-branch Arithmetic IF statement do if fed a NaN? there were hundreds
of headaches like that, and no cooperation among compiler vendors
since the language standards ignored 754). The C standards didn't
mention 754 until C99, and then left all support optional (up to the
compiler implementer whether to do it). That didn't help much for a
bigger reason: major C vendors (like Microsoft and Borland) are still
ignoring C99. "Subset" HW implementations of 754 were also common,
like some that didn't support denorms at all, others that didn't
implement the non-default rounding modes, some that ignored signed
zeroes, and several that implemented 754 endcases by generating kernel
traps to deal with infinities and NaNs, making them so much slower
than normal cases that users avoided them like death.

If I had to bet at the time, I would have put my money on 754 dying
out due to near-universal lack of language support, and incompatible
HW implementations. Most programming languages still have no sane 754
story, but the remarkable dominance of the Pentium architecture
changed everything on the HW side.

> I would have guessed that most Python platforms are
> '586 or better IA32 machines running either Windows or Linux.


Today, yes, although there are still Python users on many other OSes
and architectures. Most of the latter support 754 too now.

> They all have HW support for NaNs and Infinities.


Yes, Intel-based boxes certainly do (and have for a long time), and so
do most others now.
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      07-14-2005
On 2005-07-14, Tim Peters <(E-Mail Removed)> wrote:

> You may have forgotten how much richer the "plausible HW" landscape
> was at the time too.


I've probably blocked most of it out intentionally. I seem to
have vague, repressed, memories of working on a Sperry machine
that used base 4 floating point. And of course there was the
VAX.

> If I had to bet at the time, I would have put my money on 754
> dying out due to near-universal lack of language support, and
> incompatible HW implementations. Most programming languages
> still have no sane 754 story, but the remarkable dominance of
> the Pentium architecture changed everything on the HW side.


As messed up as I think the IA32 architecture is, I do think
Intel got FP mostly right.

--
Grant Edwards grante Yow! If I felt any more
at SOPHISTICATED I would DIE
visi.com of EMBARRASSMENT!
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      07-14-2005
On 2005-07-14, Grant Edwards <(E-Mail Removed)> wrote:
> On 2005-07-14, Tim Peters <(E-Mail Removed)> wrote:
>
>> You may have forgotten how much richer the "plausible HW" landscape
>> was at the time too.

>
> I've probably blocked most of it out intentionally. I seem to
> have vague, repressed, memories of working on a Sperry machine
> that used base 4 floating point.


No, on second thought, I think it was base-16.

--
Grant Edwards grante Yow! Yow! I want my nose
at in lights!
visi.com
 
Reply With Quote
 
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Guest
Posts: n/a
 
      07-14-2005
Grant Edwards wrote:
> I often foget how old Python is. Still, I've been using IEEE
> floating point in C programs (and depending on the proper
> production and handling of infinities and NaNs) for more than
> 20 years now. I had thought that Python might have caught up.


As should be clear by now, it hasn't. What made you think it would
have?

As Tim says, there are very strong reasons why Python *doesn't*
support IEEE 754, the primary one being lack of contributors that
improve it. I, for example, care much more about integer arithmetic
than floating point.

Regards,
Martin
 
Reply With Quote
 
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Guest
Posts: n/a
 
      07-14-2005
Grant Edwards wrote:
> 1/0 is defined by the standard as +Inf and 0/0 is NaN.


I wonder why Tim hasn't protested here: I thought this was *not*
the case. I thought IEEE 754 defined +Inf and NaN as only a possible
outcome of these operations with other possible outcomes being
exceptions... In that case, Python would comply to IEEE 754 in this
respect (although in a different way than the C implementation on
the same system).

Regards,
Martin
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      07-14-2005
On 2005-07-14, Martin v. L÷wis <(E-Mail Removed)> wrote:

>> 1/0 is defined by the standard as +Inf and 0/0 is NaN.

>
> I wonder why Tim hasn't protested here: I thought this was *not*
> the case. I thought IEEE 754 defined +Inf and NaN as only a possible
> outcome of these operations with other possible outcomes being
> exceptions...


The "exceptions" specified by the standard aren't required, but
it's "strongly recommended" that they be provided as options
for the programmer. If provided, I believe they are to be
resumable so that the user can determine what operation was
attempted on what operands and return a result if desired.

> In that case, Python would comply to IEEE 754 in this respect


My recollection is that returning Inf and NaN is to be the
default behavior, and a resumable exception is a recommended
option.

> (although in a different way than the C implementation on the
> same system).


I can't find my copy of the standard at the moment, though I
did just re-read Goldberg's 1991 discussion of the standard.

--
Grant Edwards grante Yow! My Aunt MAUREEN was
at a military advisor to IKE &
visi.com TINA TURNER!!
 
Reply With Quote
 
Tim Peters
Guest
Posts: n/a
 
      07-15-2005
[Grant Edwards]
>> 1/0 is defined by the standard as +Inf and 0/0 is NaN.


[Martin v. L÷wis]
> I wonder why Tim hasn't protested here:


Partly because this thread (unlike the other current thread on the
topic) isn't moving toward making progress, and I have little time for
this.

But mostly because Python's fp design was in no way informed by 754,
so logic-chopping on the 754 standard wrt what Python actually does is
plainly perverse <0.5 wink>.

> I thought this was *not* the case. I thought IEEE 754 defined +Inf and NaN
> as only a possible outcome of these operations with other possible
> outcomes being exceptions... In that case, Python would comply to IEEE
> 754 in this respect (although in a different way than the C implementation on
> the same system).


Ya, and Unicode defines 16-bit little-endian characters <wink>.
Seriously, the 754 standard is quite involved, and there's just no
visible point I can see to trotting out its elaborate details here.
If Python claimed to support 754, then details would be important.
Short course wrt this specific point: there's no reasonable way in
which Python's float arithmetic can be said to comply to IEEE 754 in
this case, neither in letter nor spirit. The decimal module does,
though (mutatis mutandis wrt base).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Numerics, NaNs, IEEE 754 and C99 Nick Maclaren Python 33 06-15-2006 04:46 PM
struct, IEEE-754 and internal representation ej Python 4 11-09-2005 11:54 PM
IEEE 754 floating-point "exception" -> C++ exception Lionel B C++ 0 09-23-2004 11:24 AM
IEEE-754 double class?? Auronc C++ 0 09-01-2004 08:43 AM



Advertisments