Question

Summary of the problem:

For some decimal values, when we convert the type from decimal to double, a small fraction is added to the result.

What makes it worse, is that there can be two “equal” decimal values that result in different double values when converted.

Code sample:

decimal dcm = 8224055000.0000000000m;  // dcm = 8224055000
double dbl = Convert.ToDouble(dcm);    // dbl = 8224055000.000001

decimal dcm2 = Convert.ToDecimal(dbl); // dcm2 = 8224055000
double dbl2 = Convert.ToDouble(dcm2);  // dbl2 = 8224055000.0

decimal deltaDcm = dcm2 - dcm;         // deltaDcm = 0
double deltaDbl = dbl2 - dbl;          // deltaDbl = -0.00000095367431640625

Look at the results in the comments. Results are copied from debugger’s watch.
The numbers that produce this effect have far less decimal digits than the limit of the data types, so it can’t be an overflow (I guess!).

What makes it much more interesting is that there can be two equal decimal values (in the code sample above, see “dcm” and “dcm2”, with “deltaDcm” equal to zero) resulting in different double values when converted. (In the code, “dbl” and “dbl2”, which have a non-zero “deltaDbl”)

I guess it should be something related to difference in the bitwise representation of the numbers in the two data types, but can’t figure out what! And I need to know what to do to make the conversion the way I need it to be. (like dcm2 -> dbl2)

Answer 1

Interesting – although I generally don’t trust normal ways of writing out floating point values when you’re interested in the exact results.

Here’s a slightly simpler demonstration, using DoubleConverter.cs which I’ve used a few times before.

using System;

class Test
{
    static void Main()
    {
        decimal dcm1 = 8224055000.0000000000m;
        decimal dcm2 = 8224055000m;
        double dbl1 = (double) dcm1;
        double dbl2 = (double) dcm2;

        Console.WriteLine(DoubleConverter.ToExactString(dbl1));
        Console.WriteLine(DoubleConverter.ToExactString(dbl2));
    }
}

Results:

8224055000.00000095367431640625
8224055000

Now the question is why the original value (8224055000.0000000000) which is an integer – and exactly representable as a double – ends up with extra data in. I strongly suspect it’s due to quirks in the algorithm used to convert from decimal to double, but it’s unfortunate.

It also violates section 6.2.1 of the C# spec:

For a conversion from decimal to float or double, the decimal value is rounded to the
nearest double or float value. While this conversion may lose precision, it never causes
an exception to be thrown.

The “nearest double value” is clearly just 8224055000… so this is a bug IMO. It’s not one I’d expect to get fixed any time soon though. (It gives the same results in .NET 4.0b1 by the way.)

To avoid the bug, you probably want to normalize the decimal value first, effectively “removing” the extra 0s after the decimal point. This is somewhat tricky as it involves 96-bit integer arithmetic – the .NET 4.0 BigInteger class may well make it easier, but that may not be an option for you.