Turn off ZeroDivisionError?

**endangeredmassa@gmail.com** · Feb 10 '08, 04:55 PM

Re: Turn off ZeroDivisionErr or?

Would a wrapper function be out of the question here?

def MyDivision(num, denom):
if denom==0:
return "NaN"
else
return num / denom

**Mark Dickinson** · Feb 10 '08, 05:35 PM

Re: Turn off ZeroDivisionErr or?

On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmai l.comwrote:

If I use C code to turn off the hardware signal, will that stop python from
detecting the exception, or is python checking for 0 denominator on it's
own (hope not, that would waste cycles).

Yes, Python does do an explicit check for a zero denominator. Here's
an excerpt from floatdiv.c in Objects/floatobject.c:

if (b == 0.0) {
PyErr_SetString (PyExc_ZeroDivi sionError, "float division");
return NULL;
}

This is probably the only sane way to deal with differences in
platform behaviour when doing float divisions.

**Dikkie Dik** · Feb 10 '08, 06:55 PM

Re: Turn off ZeroDivisionErr or?

Mark Dickinson wrote:

On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmai l.comwrote:

>If I use C code to turn off the hardware signal, will that stop python from
>detecting the exception, or is python checking for 0 denominator on it's
>own (hope not, that would waste cycles).

>
Yes, Python does do an explicit check for a zero denominator. Here's
an excerpt from floatdiv.c in Objects/floatobject.c:
>
if (b == 0.0) {
PyErr_SetString (PyExc_ZeroDivi sionError, "float division");
return NULL;
}
>
This is probably the only sane way to deal with differences in
platform behaviour when doing float divisions.

Are you sure?

It could very well be that 1/(smallest possible number)>(greate st
possible number). So I would also trap any errors besides trapping for
the obvious zero division.

**bearophileHUGS@lycos.com** · Feb 10 '08, 08:15 PM

Re: Turn off ZeroDivisionErr or?

Mark Dickinson:

This is probably the only sane way to deal with differences in
platform behaviour when doing float divisions.

What Python run on a CPU that doesn't handle the nan correctly?

Bye,
bearophile

**Grant Edwards** · Feb 10 '08, 08:35 PM

Re: Turn off ZeroDivisionErr or?

On 2008-02-10, Mark Dickinson <dickinsm@gmail .comwrote:

On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmai l.comwrote:

>If I use C code to turn off the hardware signal, will that stop python from
>detecting the exception, or is python checking for 0 denominator on it's
>own (hope not, that would waste cycles).

>
Yes, Python does do an explicit check for a zero denominator. Here's
an excerpt from floatdiv.c in Objects/floatobject.c:
>
if (b == 0.0) {
PyErr_SetString (PyExc_ZeroDivi sionError, "float division");
return NULL;
}
>
This is probably the only sane way to deal with differences in
platform behaviour when doing float divisions.

I've always found that check to be really annoying. Every time
anybody asks about floating point handling, the standard
response is that "Python just does whatever the underlying
platform does". Except it doesn't in cases like this. All my
platforms do exactly what I want for division by zero: they
generate a properly signed INF. Python chooses to override
that (IMO correct) platform behavior with something surprising.
Python doesn't generate exceptions for other floating point
"events" -- why the inconsistency with divide by zero?

--
Grant Edwards grante Yow! Where's th' DAFFY
at DUCK EXHIBIT??
visi.com

**Steve Holden** · Feb 10 '08, 08:35 PM

Re: Turn off ZeroDivisionErr or?

Dikkie Dik wrote:

Mark Dickinson wrote:

>On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmai l.comwrote:

>>If I use C code to turn off the hardware signal, will that stop python from
>>detecting the exception, or is python checking for 0 denominator on it's
>>own (hope not, that would waste cycles).

>Yes, Python does do an explicit check for a zero denominator. Here's
>an excerpt from floatdiv.c in Objects/floatobject.c:
>>
>if (b == 0.0) {
> PyErr_SetString (PyExc_ZeroDivi sionError, "float division");
> return NULL;
>}
>>
>This is probably the only sane way to deal with differences in
>platform behaviour when doing float divisions.

Are you sure?
>
It could very well be that 1/(smallest possible number)>(greate st
possible number). So I would also trap any errors besides trapping for
the obvious zero division.

What's so special about one? You surely don't expect the Python code to
check for all possible cases of overflow before allowing the hardware to
proceed with a division?

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

**Christian Heimes** · Feb 10 '08, 09:45 PM

Re: Turn off ZeroDivisionErr or?

Grant Edwards wrote:

I've always found that check to be really annoying. Every time
anybody asks about floating point handling, the standard
response is that "Python just does whatever the underlying
platform does". Except it doesn't in cases like this. All my
platforms do exactly what I want for division by zero: they
generate a properly signed INF. Python chooses to override
that (IMO correct) platform behavior with something surprising.
Python doesn't generate exceptions for other floating point
"events" -- why the inconsistency with divide by zero?

I'm aware result is arguable and professional users may prefer +INF for
1/0. However Python does the least surprising thing. It raises an
exception because everybody has learned at school 1/0 is not allowed.

>From the PoV of a mathematician Python does the right thing, too. 1/0 is

not defined, only the lim(1/x) for x -0 is +INF. From the PoV of a
numerics guy it's surprising.

Do you suggest that 1./0. results into +INF [1]? What should be the
result of 1/0?

Christian

[1]

Division by zero - Wikipedia

http://en.wikipedia.org/wiki/Division_by_zero#Division_by_zero_in_computer_arithmetic

**Grant Edwards** · Feb 10 '08, 10:05 PM

Re: Turn off ZeroDivisionErr or?

On 2008-02-10, Christian Heimes <lists@cheimes. dewrote:

Grant Edwards wrote:
>

>I've always found that check to be really annoying. Every
>time anybody asks about floating point handling, the standard
>response is that "Python just does whatever the underlying
>platform does". Except it doesn't in cases like this. All my
>platforms do exactly what I want for division by zero: they
>generate a properly signed INF. Python chooses to override
>that (IMO correct) platform behavior with something
>surprising. Python doesn't generate exceptions for other
>floating point "events" -- why the inconsistency with divide
>by zero?

>
I'm aware result is arguable and professional users may prefer
+INF for 1/0. However Python does the least surprising thing.

It appears that you and I are surprised by different things.

It raises an exception because everybody has learned at school
1/0 is not allowed.

You must have gone to a different school than I did. I learned
that for IEEE floating point operations a/0. is INF with the
same sign as a (except when a==0, then you get a NaN).

>>From the PoV of a mathematician Python does the right thing,
>>too. 1/0 is not defined, only the lim(1/x) for x -0 is +INF.
>>From the PoV of a numerics guy it's surprising.

>
Do you suggest that 1./0. results into +INF [1]?

That's certainly what I expected after being told that Python
doesn't do anything special with floating point operations and
leaves it all up to the underlying hardware. Quoting from the
page to linked to, it's also what the IEEE standard specifies:

The IEEE floating-point standard, supported by almost all
modern processors, specifies that every floating point
arithmetic operation, including division by zero, has a
well-defined result. In IEEE 754 arithmetic, a/0 is positive
infinity when a is positive, negative infinity when a is
negative, and NaN (not a number) when a = 0.

I was caught completely off guard when I discovered that Python
goes out of its way to violate that standard, and it resulted
in my program not working correctly.

What should be the result of 1/0?

I don't really care. An exception is OK with me, but I don't
write code that does integer divide by zero operations.

--
Grant Edwards grante Yow! does your DRESSING
at ROOM have enough ASPARAGUS?
visi.com

**Mark Dickinson** · Feb 10 '08, 10:05 PM

Re: Turn off ZeroDivisionErr or?

On Feb 10, 3:29 pm, Grant Edwards <gra...@visi.co mwrote:

platform does". Except it doesn't in cases like this. All my
platforms do exactly what I want for division by zero: they
generate a properly signed INF. Python chooses to override
that (IMO correct) platform behavior with something surprising.
Python doesn't generate exceptions for other floating point
"events" -- why the inconsistency with divide by zero?

But not everyone wants 1./0. to produce an infinity; some people
would prefer an exception.

Python does try to generate exceptions for floating-point events
at least some of the time---e.g. generating ValueErrors for
sqrt(-1.) and log(-1.) and OverflowError for exp(large_numbe r).

I agree that the current situation is not ideal. I think the ideal
would be to have a floating-point environment much like Decimal's,
where the user has control over whether floating-point exceptions
are trapped (producing Python exceptions) or not (producing
infinities
and nans). The main difficulty is in writing reliable ANSI C that
can do this across platforms. It's probably not impossible, but
it is a lot of work.

**Christian Heimes** · Feb 10 '08, 10:45 PM

Re: Turn off ZeroDivisionErr or?

Grant Edwards wrote:

You must have gone to a different school than I did. I learned
that for IEEE floating point operations a/0. is INF with the
same sign as a (except when a==0, then you get a NaN).

I'm not talking about CS and IEEE floating point ops. I was referring to
plain good old math. Python targets both newbies and professionals.
That's the reason for two math modules (math and cmath).

That's certainly what I expected after being told that Python
doesn't do anything special with floating point operations and
leaves it all up to the underlying hardware. Quoting from the
page to linked to, it's also what the IEEE standard specifies:
>
The IEEE floating-point standard, supported by almost all
modern processors, specifies that every floating point
arithmetic operation, including division by zero, has a
well-defined result. In IEEE 754 arithmetic, a/0 is positive
infinity when a is positive, negative infinity when a is
negative, and NaN (not a number) when a = 0.
>
I was caught completely off guard when I discovered that Python
goes out of its way to violate that standard, and it resulted
in my program not working correctly.

Python's a/0 outcome doesn't violate the standards because Python
doesn't promise to follow the IEEE 754 standard in the first place. Mark
and I are working hard to make math in Python more reliable across
platforms. So far we have fixed a lot of problems but we haven't
discussed the a/0 matter.

The best we could give you is an option that makes Python's floats more
IEEE 754 like:

>>from somemodule import ieee754
>>with ieee754:

.... r = a/0
.... print r
inf

Christian

**Paul Rubin** · Feb 10 '08, 10:45 PM

Re: Turn off ZeroDivisionErr or?

Christian Heimes <lists@cheimes. dewrites:

Python targets both newbies and professionals.
That's the reason for two math modules (math and cmath).

Ehhh??? cmath is for complex-valued functions, nothing to do with
newbies vs. professionals.

**Mark Dickinson** · Feb 10 '08, 10:45 PM

Re: Turn off ZeroDivisionErr or?

On Feb 10, 4:56 pm, Grant Edwards <gra...@visi.co mwrote:

Exactly. Espeically when Python supposedly leaves floating
point ops up to the platform.

There's a thread at http://mail.python.org/pipermail/pyt...ly/329849.html
that's quite relevant to this discussion. See especially the
exchanges between Michael
Hudson and Tim Peters in the later part of the thread. I like this
bit, from Tim:

"I believe Python should raise exceptions in these cases by default,
because, as above, they correspond to the overflow and
invalid-operation signals respectively, and Python should raise
exceptions on the overflow, invalid-operation, and divide-by-0
signals
by default. But I also believe Python _dare not_ do so unless it
also
supplies sane machinery for disabling traps on specific signals
(along
the lines of the relevant standards here). Many serious numeric
programmers would be livid, and justifiably so, if they couldn't get
non-stop mode back. The most likely x-platfrom accident so far is
that they've been getting non-stop mode in Python since its
beginning."

Mark

**Christian Heimes** · Feb 10 '08, 11:05 PM

Re: Turn off ZeroDivisionErr or?

Grant Edwards wrote:

A more efficient implementation? Just delete the code that
raises the exception and the HW will do the right thing.

Do you really think that the hardware and the C runtime library will do
the right thing? Python runs on a lots platforms and architectures. Some
of the platforms don't have a FPU or don't support hardware acceleration
for floating point ops for user space applications. Some platforms don't
follow IEEE 754 semantics at all.

It took us a lot of effort to get consistent results for edge cases of
basic functions like sin and atan on all platforms. Simply removing
those lines and praying that it works won't do it.

Christian

**Neal Becker** · Feb 10 '08, 11:05 PM

Re: Turn off ZeroDivisionErr or?

Christian Heimes wrote:

Grant Edwards wrote:

>A more efficient implementation? Just delete the code that
>raises the exception and the HW will do the right thing.

>
Do you really think that the hardware and the C runtime library will do
the right thing? Python runs on a lots platforms and architectures. Some
of the platforms don't have a FPU or don't support hardware acceleration
for floating point ops for user space applications. Some platforms don't
follow IEEE 754 semantics at all.
>
It took us a lot of effort to get consistent results for edge cases of
basic functions like sin and atan on all platforms. Simply removing
those lines and praying that it works won't do it.
>
Christian
>

I think, ideally, that on a platform that has proper IEEE 754 support we
would rely on the hardware, and only on platforms that don't would we add
extra software emulation.

With proper hardware support, the default would be a hardware floating pt
exception, which python would translate.

If the user wanted, she should be able to turn it off during some
calculation (but that would not be the default).

Turn off ZeroDivisionError?

Turn off ZeroDivisionError?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment