Question

One error I stumble upon every few month is this one:

        double x = 19.08;
        double y = 2.01;
        double result = 21.09;

        if (x + y == result)
        {
            MessageBox.Show("x equals y");
        }
        else
        {
            MessageBox.Show("that shouldn't happen!");  // <-- this code fires
        }

You would suppose the code to display “x equals y” but that’s not the case.
The short explanation is that the decimal places are, represented as a binary digit, do not fit into double.

Example:
2.625 would look like:

10.101

because

1-------0-------1---------0----------1  
1 * 2 + 0 * 1 + 1 * 0.5 + 0 * 0.25 + 1 * 0,125 = 2.65

And some values (like the result of 19.08 plus 2.01) cannot be be represented with the bits of a double.

One solution is to use a constant:

        double x = 19.08;
        double y = 2.01;
        double result = 21.09;
        double EPSILON = 10E-10;

        if ( x + y - result < EPSILON )
        {
            MessageBox.Show("x equals y"); // <-- this code fires
        }
        else
        {
            MessageBox.Show("that shouldn't happen!");
        }

If I use decimal instead of double in the first example, the result is “x equals y”.
But I’m asking myself If this is because of “decimal” type is not vulnerable of this behaviour or it just works in this case because the values “fit” into 128 bit.

Maybe someone has a better solution than using a constant?

Btw. this is not a dotNet/C# problem, it happens in most programming languages I think.

Answer 1

Decimal will be accurate so long as you stay within values which are naturally decimals in an appropriate range. So if you just add and subtract, for example, without doing anything which would skew the range of digits required too much (adding a very very big number to a very very small number) you will end up with easily comparable results. Multiplication is likely to be okay too, but I suspect it’s easier to get inaccuracies with it.

As soon as you start dividing, that’s where the problems can come – particularly if you start dividing by numbers which include prime factors other than 2 or 5.

Bottom line: it’s safe in certain situations, but you really need to have a good handle on exactly what operations you’ll be performing.

Note that it’s not the 128-bitness of decimal which is helping you here – it’s the representation of numbers as floating decimal point values rather than floating binary point values. See my articles on .NET binary floating point and decimal floating point for more information.