I do not know why Ceiling behave like in the below image
Why is processingFee != Settings.PaymentProcessingFeeInPercentage * prizesSum ?
+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.
Jens
2010-07-01 14:23:13
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
2010-07-01 14:35:58
@Mark: You are right, of course. 130 = 0.10000010 x 2^8 =)
Jens
2010-07-01 15:00:56
+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.
SLaks
2010-07-01 14:23:55
+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
2010-07-01 14:24:26
Um, 130 can *certainly* be represented exactly as a binary floating point number. However, 0.05 can't.
Jon Skeet
2010-07-01 14:29:45
130 is 10000010 in binary and definitely can be represented exactly as an IEEE754 floating point.
Martin Smith
2010-07-01 14:30:54
+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?
MainMa
2010-07-01 14:24:36
+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
2010-07-01 14:24:42
@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).
Brian
2010-07-01 14:52:41
A:
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
2010-07-01 14:26:11
@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
2010-07-01 14:28:45
Ah yes, thank you. And yes on the second point, too. What I meant was "double is no more appropraite than float".
maxwellb
2010-07-01 14:30:36
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
2010-07-01 14:33:29
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
2010-07-01 14:37:45
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
2010-07-01 15:04:20
A:
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 ) );
maxwellb
2010-07-01 14:26:50