I do not know why Ceiling behave like in the below image

Why is processingFee != Settings.PaymentProcessingFeeInPercentage * prizesSum ?

View image at full size

alt text

+4  A: 

This is a result of the floating point representation of the numbers involved. See the wikipedia. Probably 0.05 has an infinite base 2 representation as a double, so the value Math.Ceiling actually sees might be slightly larger than 130.

To be absolutely annoyingly precise: a small (mathematical) integer such as 130 has an accurate finite representation in IEEE floating point numbers (either 32 bit or 64 bit). What may not be representable in floating point numbers is the (mathematical) real number close to 130 that OP thinks is equal to 130
High Performance Mark
@Mark: You are right, of course. 130 = 0.10000010 x 2^8 =)
+2  A: 

You're seeing floatng-point imprecision.
The actual base-2 representation of 0.05 is a tiny bit more than 0.05, so the product is a tiny bit more than 130.0.
Therefore, Math.Ceiling is rounding up.

Change your floats and doubles to decimal.

+1  A: 

This is due to the internal storage format for a floating point number being inherently inexact when the number is represented in decimal. There are many, many questions on this on Stack Overflow.

The number you are returning is probably something like 130.000000000000001 since the numbers in your calculation can't be represented exactly as a binary floating point number.

David M
Um, 130 can *certainly* be represented exactly as a binary floating point number. However, 0.05 can't.
Jon Skeet
130 is 10000010 in binary and definitely can be represented exactly as an IEEE754 floating point.
Martin Smith
D'oh. Of course.
David M
+1  A: 

IMHO, it's probably something to do with floating point precision. In other words, 2600 × 0.05 gives 130.0000...001 rather than 130.

What if you try to round the result first, than call Math.Ceiling?

+22  A: 

Your percentage isn't actually 0.05. It's a value close to 0.05... and probably a little bit more than 0.05. Thus when it's multiplied by 2600, you're getting a value just over 130.0... which is then being "ceilinged" to 131.0.

Using a little tool I wrote a while ago (available from this page about .NET binary floating point types) it looks like the actual float value closest to 0.05 is 0.0500000007450580596923828125. For doubles, it's 0.05000000000000000277555756156289135105907917022705078125.

Moral of the story: don't use float for this sort of thing - use decimal. Or if you're just trying to represent a percentage, if it's okay to actually be only accurate to one percent, use an integer value 0-100.

Jon Skeet
+1 for suggesting `Decimal`
will work with decimal, and even double for all variables
@pixel3cs: No, don't use `double`, either. It has the same problems as `float`. The reason `decimal` avoids these issues is because it is a floating point base 10 number instead of a floating point base 2 number. In general, `decimal` is going to be your safest choice for working with money, because the internal representation of `decimal` matches the thing you are trying to represent (though less efficiently).
+1. never, ever store money in a float or double.

In my compiler, when i lookup the multiply value, it says 130.00000193715096, so the math.ceiling result is ok. The problem is the limited precision of the float data type.

Try using 'double' instead, if it is possible.

Diego Pereyra
OP is using double.
@maxwellb: Not for the value of Settings.PaymentProcessingFeeInPercentage. However, `double` would still give the "wrong" answer. It's simply inappropriate to use `float` or `double` here.
Jon Skeet
Ah yes, thank you. And yes on the second point, too. What I meant was "double is no more appropraite than float".
double in this case gives the expected result, anyway, we know the best option is to analyze wich precision is really needed for that data.
Diego Pereyra
Problem is not limited precision of the float data type, it is lack of understanding of how to use floating point arithmetic. SO is covered in such lack of understanding.
High Performance Mark
I agree, that's why I said that an analysis is necessary. You can even find out that you can do the necessary arithmetic with integers without losing precision (and it can even be faster).
Diego Pereyra

If you use floating point numbers in a large banking operation, don't let me float my money in your bank. Use decimals, or integers of the least common denominator, i.e. cents.

You could however, use a Math.Round, to help you use doubles or floats, if you make assumptions about how large your calculations will get. i.e.:

double processingFee = Math.Ceiling( Math.Round( 
    Settings.PaymentProcessingFeeInPercentage * prizesSum, 2 ) );
Note that `decimal` in C# is still a floating point type. It's just a floating *decimal* point rather than a floating *binary* point.
Jon Skeet
Still "valid" only to a certain number of sigfigs. Good distinction.