 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / October 2007Divide by Zero Question.
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 > Hello! I was working on some code the other day, and I came across an odd > discrepancy between the decimal and the double type. [quoted text clipped - 6 lines] > > 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.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > Hello! I was working on some code the other day, and I came across an odd > discrepancy between the decimal and the double type. [quoted text clipped - 6 lines] > > 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 > Hello! I was working on some code the other day, and I came across an odd > discrepancy between the decimal and the double type. [quoted text clipped - 10 lines] > > 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. > 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/2007/09/22/error-handling-best-practices/. Cheers! MW > > That's not an exception you want to catch either way. Catching that > > exception is 400x slower (literally) than checking the divisor for [quoted text clipped - 3 lines] > > Christof > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.