5

I'm experiencing strange issue when casting decimal to double.

Following code returns true:

Math.Round(0.010000000312312m, 2) == 0.01m //true

However, when I cast this to double it returns false:

(double)Math.Round(0.010000000312312m, 2) == (double)0.01m //false

I've experienced this problem when I wanted to use Math.Pow and was forced to cast decimal to double since there is no Math.Pow overload for decimal.

Is this documented behavior? How can I avoid it when I'm forced to cast decimal to double?

Screenshot from Visual Studio:

Screenshot from Visual Studio

Casting Math.Round to double me following result:

(double)Math.Round(0.010000000312312m, 2)   0.0099999997764825821   double
(double)0.01m   0.01    double

UPDATE

Ok, I'm reproducing the issue as follows:

  1. When I run WPF application and check the output in watch just after it started I get true like on empty project.
  2. There is a part of application that sends values from the slider to the calculation algorithm. I get wrong result and I put breakpoint on the calculation method. Now, when I check the value in watch window I get false (without any modifications, I just refresh watch window).
  3. As soon as I reproduce the issue in some smaller project I will post it here.

UPDATE2

Unfortunately, I cannot reproduce the issue in smaller project. I think that Eric's answer explains why.

empi
  • 15,755
  • 8
  • 62
  • 78
  • 1
    Your second statement also returns `true`. – Rotem Aug 21 '13 at 15:05
  • 3
    you shouldn't use equality checks on double - use some epsilon value – ne2dmar Aug 21 '13 at 15:06
  • the second statement returns true for me as well, in VS2012, .NET 4.0 – Jonesopolis Aug 21 '13 at 15:08
  • @Rotem: it returns false on vs2012, .net 4.0 – empi Aug 21 '13 at 15:08
  • @empi I am also on .net 4.0, something strange going on. Is this the exact statement you're testing? – Rotem Aug 21 '13 at 15:10
  • If I was you I'd try that statement in a clean project, like `private void button1_Click(object sender, EventArgs e) { int Fool = 0; if (Math.Round(0.010000000312312m, 2) == 0.01m) { Fool = 1; } if ((double)Math.Round(0.010000000312312m, 2) == (double)0.01m) { Fool = 2; } MessageBox.Show(Fool.ToString()); }` because I'm also getting true on VS2010 .Net 4.03 – Medic3000 Aug 21 '13 at 15:12
  • See these links. Double and decimal are not always exact. http://msdn.microsoft.com/en-us/library/system.double.aspx#Precision http://msdn.microsoft.com/en-us/library/364x0z75.aspx – paparazzo Aug 21 '13 at 15:24
  • @Blam How does that explain that only OP is getting `false` while others `true`? – Rotem Aug 21 '13 at 15:25
  • I'm having trouble reproducing the issue on empty project. It's WPF application and the code was written using Portable Class Library. – empi Aug 21 '13 at 15:28
  • @rotem Was posted as a comment not an answer I suspect precision as the cause. – paparazzo Aug 21 '13 at 15:29

2 Answers2

12

People are reporting in the comments here that sometimes the result of the comparison is true and sometimes it is false.

Unfortunately, this is to be expected. The C# compiler, the jitter and the CPU are all permitted to perform arithmetic on doubles in more than 64 bit double precision, as they see fit. This means that sometimes the results of what looks like "the same" computation can be done in 64 bit precision in one calculation, 80 or 128 bit precision in another calculation, and the two results might differ in their last bit.

Let me make sure that you understand what I mean by "as they see fit". You can get different results for any reason whatsoever. You can get different results in debug and retail. You can get different results if you make the compiler do the computation in constants and if you make the runtime do the computation at runtime. You can get different results when the debugger is running. You can get different results in the runtime and the debugger's expression evaluator. Any reason whatsoever. Double arithmetic is inherently unreliable. This is due to the design of the floating point chip; double arithmetic on these chips cannot be made more repeatable without a considerable performance penalty.

For this and other reasons you should almost never compare two doubles for exact equality. Rather, subtract the doubles, and see if the absolute value of the difference is smaller than a reasonable bound.

Moreover, it is important that you understand why rounding a double to two decimal places is a difficult thing to do. A non-zero, finite double is a number of the form (1 + f) x 2e where f is a fraction with a denominator that is a power of two, and e is an exponent. Clearly it is not possible to represent 0.01 in that form, because there is no way to get a denominator equal to a power of ten out of a denominator equal to a power of two.

The double 0.01 is actually the binary number 1.0100011110101110000101000111101011100001010001111011 x 2-7, which in decimal is 0.01000000000000000020816681711721685132943093776702880859375. That is the closest you can possibly get to 0.01 in a double. If you need to represent exactly that value then use decimal. That's why its called decimal.

Incidentally, I have answered variations on this question many times on StackOverflow. For example:

Why differs floating-point precision in C# when separated by parantheses and when separated by statements?

Also, if you need to "take apart" a double to see what its bits are, this handy code that I whipped up a while back is quite useful. It requires that you install Solver Foundation, but that's a free download.

http://ericlippert.com/2011/02/17/looking-inside-a-double/

Community
  • 1
  • 1
Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
0

This is documented behavior. The decimal data type is more precise than the double type. So when you convert from decimal to double there is the possibility of data loss. This is why you are required to do an explicit conversion of the type.

See the following MSDN C# references for more information:

decimal data type: http://msdn.microsoft.com/en-us/library/364x0z75(v=vs.110).aspx

double data type: http://msdn.microsoft.com/en-us/library/678hzkk9(v=vs.110).aspx

casting and type conversion: http://msdn.microsoft.com/en-us/library/ms173105.aspx

Nick Zimmerman
  • 1,471
  • 11
  • 11
  • 2
    This explanation does not explain the results shown in the comments above: namely, that sometimes the result is true and sometimes it is false. – Eric Lippert Aug 21 '13 at 15:32