[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Turn off ZeroDivisionError?

Neal Becker

2/9/2008 10:04:00 PM

I'd like to turn off ZeroDivisionError. I'd like 0./0. to just give NaN,
and when output, just print 'NaN'. I notice fpconst has the required
constants. I don't want to significantly slow floating point math, so I
don't want to just trap the exception.

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).
62 Answers

Richard Szopa

2/9/2008 11:10:00 PM

0

On Feb 9, 11:03 pm, Neal Becker <ndbeck...@gmail.com> wrote:
> I'd like to turn off ZeroDivisionError. I'd like 0./0. to just give NaN,
> and when output, just print 'NaN'. I notice fpconst has the required
> constants. I don't want to significantly slow floating point math, so I
> don't want to just trap the exception.

What you are trying to do looks like something very, very wrong, in
the vast majority of cases. Think: normal Python code and the
interpreter itself are written under the assumption that dividing by
zero doesn't pass silently. Changing it is asking for bogus behavior.

Have you actually timed how big is the overhead of catching the
exception?

In [83]: import timeit

In [84]: x = """try:
1.0/rand.next()
except:
pass"""

In [85]: t = timeit.Timer(x, 'import random \nrand =
iter([random.randint(0,10) for i in xrange(1000000)])')

In [86]: x_nozero = "1.0/rand.next()"

In [87]: t_nozero = timeit.Timer(x_nozero, 'import random \nrand =
iter([random.randint(1,10) for i in xrange(1000000)])')

In [88]: t.repeat()
Out[88]: [0.91399192810058594, 0.8678128719329834,
0.86738419532775879]

In [89]: t_nozero.repeat()
Out[89]: [0.64040493965148926, 0.58412599563598633,
0.59886980056762695]

As you can see, the overhead isn't so huge.

If this overhead is too big for you, you should consider using a
different language (C? Fortran?) or at least a numeric package for
Python (NumPy?).

Anyway, turning off division by zero signaling looks like the wrong
answer to the wrong question.

HTH,

-- Richard

endangeredmassa@gmail.com

2/10/2008 4:47:00 PM

0

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

2/10/2008 5:33:00 PM

0

On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmail.com> wrote:
> 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_ZeroDivisionError, "float division");
return NULL;
}

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

Dikkie Dik

2/10/2008 6:54:00 PM

0

Mark Dickinson wrote:
> On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmail.com> wrote:
>> 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_ZeroDivisionError, "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)>(greatest
possible number). So I would also trap any errors besides trapping for
the obvious zero division.

Bearophile

2/10/2008 8:10:00 PM

0

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

2/10/2008 8:30:00 PM

0

On 2008-02-10, Mark Dickinson <dickinsm@gmail.com> wrote:
> On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmail.com> wrote:
>> 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_ZeroDivisionError, "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

2/10/2008 8:31:00 PM

0

Dikkie Dik wrote:
> Mark Dickinson wrote:
>> On Feb 9, 5:03 pm, Neal Becker <ndbeck...@gmail.com> wrote:
>>> 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_ZeroDivisionError, "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)>(greatest
> 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.hold...

Neal Becker

2/10/2008 9:19:00 PM

0

endangeredmassa@gmail.com wrote:

> Would a wrapper function be out of the question here?
>
> def MyDivision(num, denom):
> if denom==0:
> return "NaN"
> else
> return num / denom

I bought a processor that has hardware to implement this. Why do I want
software to waste time on it?

Christian Heimes

2/10/2008 9:40:00 PM

0

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]
http://en.wikipedia.org/wiki/Division_by_zero#Division_by_zero_in_computer_...

Jeff Schwab

2/10/2008 9:51:00 PM

0

Neal Becker wrote:
> endangeredmassa@gmail.com wrote:
>
>> Would a wrapper function be out of the question here?
>>
>> def MyDivision(num, denom):
>> if denom==0:
>> return "NaN"
>> else
>> return num / denom
>
> I bought a processor that has hardware to implement this. Why do I want
> software to waste time on it?

Will the amount of time wasted by the software exceed the amount of time
required to implement Python-level access to the hardware feature? At
any rate, the work-around should at least let you work on the rest of
the application, while a more efficient implementation can be developed.