# Divide by Zero Question.

=?Utf-8?B?bWljaGFlbGd3ZWllcg==?=
Guest
Posts: n/a

 12th Oct 2007
Hello! I was working on some code the other day, and I came across an odd
discrepancy between the decimal and the double type.

If I attempt to divide a decimal by zero, the framework throws an error.
If I attempt to divide a double by zero, the framework returns infinity.

From a mathematical standpoint, it would seem to me that the decimal handles
this division correctly, while the double's handling of this is flawed.

Is there a practical reason why these two types handle this so differently?

Mike

Jon Skeet [C# MVP]
Guest
Posts: n/a

 12th Oct 2007
michaelgweier <(E-Mail Removed)> wrote:
> Hello! I was working on some code the other day, and I came across an odd
> discrepancy between the decimal and the double type.
>
> If I attempt to divide a decimal by zero, the framework throws an error.
> If I attempt to divide a double by zero, the framework returns infinity.
>
> From a mathematical standpoint, it would seem to me that the decimal handles
> this division correctly, while the double's handling of this is flawed.
>
> Is there a practical reason why these two types handle this so differently?

In a word, standards. At least, I suspect that's the reason.
float/double follow the IEC 60559 standard rules for arithmetic,
including division by zero resulting in an "infinite" value rather than
throwing an exception.

Decimal doesn't (or at least doesn't *have* to - the C# spec allows for
the possibility) support an "infinite" value whereas float/double do.
Similar decimal doesn't have a NaN specified.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet

Peter Duniho
Guest
Posts: n/a

 12th Oct 2007
michaelgweier wrote:
> Hello! I was working on some code the other day, and I came across an odd
> discrepancy between the decimal and the double type.
>
> If I attempt to divide a decimal by zero, the framework throws an error.
> If I attempt to divide a double by zero, the framework returns infinity.
>
> From a mathematical standpoint, it would seem to me that the decimal handles
> this division correctly, while the double's handling of this is flawed.
>
> Is there a practical reason why these two types handle this so differently?

I suspect it has to do with the FPU behavor, since I would expect the
double to be handled by hardware, but the decimal type to be handled in
software.

There may in fact be a way to set the FPU to raise an exception in the
divide by zero case. Whether this would be propagated back to your
managed code, I don't know.

Pete

=?Utf-8?B?bWljaGFlbGd3ZWllcg==?=
Guest
Posts: n/a

 12th Oct 2007
Thank you. I appreciate the quick answers!

MW

"michaelgweier" wrote:

> Hello! I was working on some code the other day, and I came across an odd
> discrepancy between the decimal and the double type.
>
> If I attempt to divide a decimal by zero, the framework throws an error.
> If I attempt to divide a double by zero, the framework returns infinity.
>
> From a mathematical standpoint, it would seem to me that the decimal handles
> this division correctly, while the double's handling of this is flawed.
>
> Is there a practical reason why these two types handle this so differently?
>
>
> Mike

not_a_commie
Guest
Posts: n/a

 12th Oct 2007
That's not an exception you want to catch either way. Catching that
exception is 400x slower (literally) than checking the divisor for
zero with an "if" statement.

Christof Nordiek
Guest
Posts: n/a

 15th Oct 2007
"not_a_commie" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> That's not an exception you want to catch either way. Catching that
> exception is 400x slower (literally) than checking the divisor for
> zero with an "if" statement.
>

How did you measure this?

Christof

not_a_commie
Guest
Posts: n/a

 15th Oct 2007
> How did you measure this?

Okay, so my measurement wasn't exactly fair; it was assuming an awful
lot of divide by zeros. If you only divide by zero one in a thousand
times, the exception might be worth it. I did my measurements a number
of months ago. It's logged as MS feedback item 256733.

=?Utf-8?B?bWljaGFlbGd3ZWllcg==?=
Guest
Posts: n/a

 16th Oct 2007
I'd actually blogged some similar results to try catch timing recently. See
my post at
http://dotnetthoughts.wordpress.com/...est-practices/.

Cheers!

MW

"Christof Nordiek" wrote:

> "not_a_commie" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:(E-Mail Removed)...
> > That's not an exception you want to catch either way. Catching that
> > exception is 400x slower (literally) than checking the divisor for
> > zero with an "if" statement.
> >

> How did you measure this?
>
> Christof
>
>

Christof Nordiek
Guest
Posts: n/a

 26th Oct 2007
"michaelgweier" <(E-Mail Removed)> schrieb im
Newsbeitrag news:66C70105-9031-4B88-A2D4-(E-Mail Removed)...
> I'd actually blogged some similar results to try catch timing recently.
> See
> my post at
> http://dotnetthoughts.wordpress.com/...est-practices/.
>

The first thing I see from that blog is, that Exceptions are much slower in
the IDE than without. I felt that often, but never measured it.
Second: the version with Exception runs 250 times resp. 500 ns slower. So
the blog says nothing about the performance, it still gives a rough measure
of when this will be a performance issue and when not.
Thanks for the work.

Christof

 Thread Tools Rate This Thread Rate This Thread: 5 : Excellent 4 : Good 3 : Average 2 : Bad 1 : Terrible

 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 OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Gord Dibben Microsoft Excel Misc 5 4th Mar 2005 08:13 PM Bernie Deitrick Microsoft Excel Misc 0 21st Sep 2004 06:40 PM =?Utf-8?B?Y29tcGFyZSBsaXN0IEEgYW5kIGxpc3QgQUI=?= Microsoft Excel Misc 0 21st Sep 2004 05:35 PM JUAN Microsoft Excel Programming 6 6th May 2004 07:05 AM Ava Microsoft Access Reports 2 8th Jul 2003 02:26 PM

Features