This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why is floating point arithmetic in C# imprecise?
Console.WriteLine(0.5f * 2f); // 1
Console.WriteLine(0.5f * 2f - 1f); // 0
Console.WriteLine(0.1f * 10f); // 1
Console.WriteLine(0.1f * 10f - 1f); // 1.490116E-08
Why does 0.1f * 10f - 1f end up being 1.490116E-08 (0.0000001490116)?
See Wiki: Floating Point. float/double/decimal are relative precision types. Not all values (of which there are infinitely many) can be exactly stored. You are seeing the result of this loss of accuracy. This is why it is almost always correct to use |a - b| < small_delta for float-point comparisons.
Because floating operations are not precise, take a look here:
http://en.wikipedia.org/wiki/Floating_point
section Some other computer representations for non-integral numbers. 0.1 cannot finitely be represented in base 2.
Take a look at What Every Computer Scientist Should Know About Floating-Point Arithmetic.
Read this (explains quite exactly this case): http://www.exploringbinary.com/the-answer-is-one-unless-you-use-floating-point/
Easy, approximations accumulate.
0.5 is representable exactly in floating point, which is why 0.5*2 = 1 exactly.
However, 0.1 is not representable exactly, hence 0.1*10 is not exactly 1.
Related
This question already has answers here:
C# midpointrounding down to zero
(3 answers)
Closed 4 years ago.
If I have a double, and want to round it down to the nearest quarter value (0.25), is this possible?
Each of these give me 0.5 and should actually give me 0.25:
Math.Round(0.499999, 2, MidpointRounding.AwayFromZero);
Math.Round(0.499999, 2, MidpointRounding.ToEven);
Is there any notion of always rounding "down"?
This question is related to "nearest" rounding. I don't need that
The "duplicate" is entirely based on NEAREST rounding. that is utterly irrelevant to me. I am not asking about NEAREST. I am asking about always rounding DOWN. Notice that 0.499999 is very NEAR to 0.5 - and that is not what I want. I want 0.49999 to become 0.25 (DOWN)
double x = 0.4999;
double answer = Math.Truncate(4*x)/4; // result: 0.25
This question already has answers here:
Truncate Two decimal places without rounding
(24 answers)
Closed 4 years ago.
For example if I divide 1050 / 256 I get 4.1015625. I need the value of first digit after decimal point (1 in this case). I don't want to involve ToString() conversions and then parsing it into digit again.
This picture for itsme86:
This picture for Jeroen Mostert:
What about:
decimal result = 4.1015625m;
result = result - (int)result;
result = Decimal.Round(result, 1, MidpointRounding.AwayFromZero);
This can be combined into one line if needed but is more readable this way.
Math.Floor((4.1015625 - Math.Floor(4.1015625)) * 10)
I would do it this way:
First i would subtract the the number before the decimal seperator of the given number.
Then I would multiply it by 10.
Example: 4.2 - 4 = .2 * 10 = 2
NOTE: You cannot use floating point numbers for accurate mathematical operations, as some values cannot be represented properly. So always cast to/use decimal and not float/double if you need exact values like this.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 7 years ago.
AFAIK .NET's default round option is to even, so Math.Round(1.225,2) should give 1.22 but it gives 1.23.
Math.Round(2.225,2) = 2.22
Math.Round(100.225,2) = 100.22
all the values I tried rounds to nearest even but only 1.225 and -1.225 rounds to 1.23 and -1.23.
The main problem is that in float and double, the amount of decimal places is not part of the value, and the precision isn't decimal, but rather, binary. And there's no finite binary number that can represent 1.225 exactly.
So when you do Math.Round(1.225f, 2), you're actually doing something more like Math.Round(1.22500002f, 2) - there's no midpoint rounding involved.
The same problem appears with Math.Round(2.225f, 2) - it's just that the "real" value is slightly smaller than 2.225f, so the result rounds down. But there's still no midpoint rounding involved.
If you need decimal precision, use decimal. Neither float nor double are designed for decimal precision - they're fine for e.g. physics calculations, but not for e.g. accounting.
1.225 can't be represented exactly in floating point, so you're really rounding 1.225000023841858.
This question already has answers here:
How does modulus operation works with float data type?
(2 answers)
Closed 7 years ago.
Newbie in C#, trying to work out a simple calculation.
float old x=300
float Distance=300
float pitch=0.8
int sign=1
new x= old x - (sign * (Distance % pitch) * 0.5 f)
The value generated by program for new x is 299.6 (which I don't understand).
The value for (Distance % pitch) is 0.7999955. If you calculate manually 300 modulo 0.8 is 0. I am guessing modulo function behaves differently for float values but i don't know how. Or it is calculated as 300 percentage of 0.8?
Explanation on this will be much appreciated.
Never expect binary floating-point calculations (using float or double) on decimal floating point values (e.g. 0.8) to give exact results.
The problem is that most of decimal numbers cannot be represented exactly in a binary floating-point format. You can think of it as trying to represent 1/3 in a decimal notation. It's not possible.
In your case, 0.8f is not really 0.8. If you cast the value to double to get some extra precision, you will see it's closer to 0.800000011920929
float pitch = 0.8f;
Console.WriteLine((double)pitch); // prints 0.800000011920929
This question already has answers here:
comparing float inequality (in python)
(2 answers)
Closed 9 years ago.
0.1 + 0.2 == 0.3 ==> False
I tried this in python, c#, c++, F#, Visual Basic.NET,ASP.NET!
0.1 + 0.2 == 0.30000000000000004 ==> True
This is True for all languages I mentioned above. Why this illogical inequality happens?
Python has a decimal library that will allow you to evaluate this to true (while also explaining that why its false as you have it), and in fact, they use almost the same exact example: http://docs.python.org/2/library/decimal.html
The exactness carries over into arithmetic. In decimal floating point, 0.1 + 0.1 + 0.1 - 0.3 is exactly equal to zero
Also related, "What every computer scientist should know about floating point", a seminal article written many years ago and still true today: http://www.fer.unizg.hr/_download/repository/paper%5B1%5D.pdf
You might want to give this a read: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (What Every Computer Scientist Should Know About Floating-Point Arithmetic)
The short answer is that in binary 0.1 is a repeating fraction, it's "somewhere" between 1/8 and 1/16 so there is no 'bit exact' representation of 0.1 (or 0.2). When comparing floating point values you always have to do so within an epsilon value the prevent such problems.
Read this from the Python docs; it applies pretty much verbatim to all languages:
http://docs.python.org/2/tutorial/floatingpoint.html
For comparing floating point number, use this pattern:
Math.Abs(NumberToCompare1 - NumberToCompare2) < 0.01
Where 0.01 is the Epsilon, the precision of the operation.