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

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
If replying to the group, please do not mail me too

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

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?
>
> Thanks in advance!
>
> Mike

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.

"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

> 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.

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
>
>

"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