Divide by Zero Question.

[Guest]

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?

Thanks in advance!

Mike

 

[Jon Skeet [C# MVP]]

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.

 

[Peter Duniho]

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

 

[Guest]

Thank you. I appreciate the quick answers!

MW

 

[not_a_commie]

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]

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]

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.

 

[Guest]

I'd actually blogged some similar results to try catch timing recently. See
my post at
http://dotnetthoughts.wordpress.com/2007/09/22/error-handling-best-practices/.

Cheers!

MW

 

[Christof Nordiek]

I'd actually blogged some similar results to try catch timing recently.
See
my post at
http://dotnetthoughts.wordpress.com/2007/09/22/error-handling-best-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