Why exactly 0.09f - 0.01f == 0.0800000057f? [duplicate] - c#

This question already has answers here:
Why does floating-point arithmetic not give exact results when adding decimal fractions?
(31 answers)
Closed 7 years ago.
I know that floating point variable stores the number in a sign-exponent-fraction format (as it's stated in the IEEE 754), it's never precise and I should probably never compare two floats without specifying the precision.
But why exactly 0.09f - 0.01f gives you the value of 0.0800000057f? What exactly happens in under the hood of the .NET VM and in the memory when I do that subtraction?

0.09 is represented as 00111101101110000101000111101100 in ieee-754, which is closest to the decimal value of 0.09000000357627869
0.01 is represented as 00111100001000111101011100001010 in ieee-754, which is closest to the decimal value of 0.009999999776482582
Their subtraction yields 00111101101000111101011100001011 which is closest to the decimal value of 0.08000000566244125
You can see how the actual subtraction is done here

Related

hardcoded double variable with 0.3 value turns into 0.299999992 [duplicate]

This question already has answers here:
Why is floating point arithmetic in C# imprecise?
(3 answers)
Closed 7 years ago.
In my computer when I harcode a variable with 0.3(or maybe some other value) of value and I debug and check the variable's value , its value is 0.29999992 but in my friends computer, it stays in 0.3.
//stores 0.29999992
double variable= 0.3;
is there a configuration problem or something related?
Thanks
This is just an artifact of how binary floating-point works. There is no way of accurately representing 0.3 in a double (or a float for that matter). If you need that (e.g. for monetary applications), use decimal instead.
Welcome to the world of floating point numbers. Some, seemingly innocuous numbers cannot be represented exactly in floating point notation. A very close approximation is used instead.

Why 2.0 % 0.1 gives 0.09999999 on debugging How to make the solution if i have to do solution if(doubleVar ==0) [duplicate]

This question already has answers here:
Why is floating point arithmetic in C# imprecise?
(3 answers)
Closed 8 years ago.
I am trying to find out modulo in c# as i know remainder is obtained on doing a modulo b= remainder so here a%b=remainder the same i tried to do like this:
var distanceFactor = slider.Value % distance;
But the value on debugging of slider.Value= 2.0 and distance =0.1 and distanceFactor i found surprisingly is 0.0999999999.. and i was expecting it to be 0.
Is it due to var ? what could be the reason for this non zero value.?
And how to do the solution of this problem ? because on rounding of this 0.0999999999 becomes 0.1 ans my control never go in condition if(distanceFactor==0) (and roundoff is also necessary in current situation).Is there any alternative to achieve it ?
This is expected behavior. A floating point number does not exactly represent a decimal number like the type decimal would do. Look at What Every Computer Scientist Should Know About Floating-Point Arithmetic for a detailed description.

Why Math.Round() works differently in C# [duplicate]

This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 8 years ago.
First I noticed that Math.Round() doesn't round for 2 digits as I as for:
double dd = Math.Round(1.66666, 2);
Result:
dd = 1.6699999570846558;
and then I created a new project with same .NET framework and the result is 1.67 now as it should been in the first place.
I've never seen Round behaving like this before, what is causing this problem?
Like the other comments mentioned, use decimal to hold the returned value:
decimal dd = Math.Round(1.66666M, 2);
The issue you described has nothing to do with the Round() function. You can read a bit about how the floating point numbers & fixed point numbers work, but the short explanation is:
With floating point variables (e.g. double), you cannot guarantee the precision of the number you save it them. So when you save something like 1.67 in a variable of the type double and then you check the value later on, therer is no guarantee you will get exactly 1.67. You may get a value like 1.66999999 (similar to what you got) or like 1.6700000001.
Fixed point variables (e.g. decimal) on the other hand, will give you that precision, so if you save 1.67, you will always get 1.67 back.
Please note that the Round() function returns the same type that you pass to it, so to make return a decimal, you need to pass it 1.66666M which is a decimal value rather than 1.66666 which is a floating point number.

float.Parse returns incorrect value [duplicate]

This question already has answers here:
Why does floating-point arithmetic not give exact results when adding decimal fractions?
(31 answers)
Closed 6 years ago.
I have a string X with value 2.26
when I parse it using float.Parse(X) ..it returns 2.2599999904632568. Why so? And how to overcome this ?
But if instead I use double.Parse(X) it returns the exact value, i.e. 2.26.
EDIT: Code
float.Parse(dgvItemSelection[Quantity.Index, e.RowIndex].Value.ToString());
Thanks for help
This is due to limitations in the precision of floating point numbers. They can't represent infinitely precise values and often resort to approximate values. If you need highly precise numbers you should be using Decimal instead.
There is a considerable amount of literature on this subject that you should take a look at. My favorite resource is the following
What Every Computer Scientist Should Know About Floating Point
Because floats don't properly represent decimal values in base 10.
Use a Decimal instead if you want an exact representation.
Jon Skeet on this topic
Not all numbers can be repesented exactly in floating point. Approximations are made and when you have operation after operation on an unexact number the situation gets worse.
See this Wikipedia entry for an example: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
If you changed you inputs to something that can be represented exactly by floating point (like 1/8), it would work. Try the number 2.25 and it will work as expected.
The only numbers that will work exactly are numbers that can be represented by the sum of any of 1/2, 1/4, 1/8, 1/16, etc since those numbers are represented by the binary 0.1, 0.01, 0.001, 0.0001, etc.
This situation happens with all floating point systems, by nature. .Net, JavaScript, etc.
It is returning the best approximation to 2.26 that is possible in a float. You're probably getting more significant digits than that because your float is being printed as a double instead of a float.
When I test
var str = "2.26";
var flt = float.Parse(str);
flt is exactly 2.26 in the VS debugger.
How do you see what it returns?

round decimal values up to the nearest of 0.01? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
c# - How do I round a decimal value to 2 decimal places (for output on a page)
How to round decimal value up to nearest 0.05 value??, the linked SO post also discusses the similar topic, but its not the output i expected.
I need to convert the decimal values like this
16.489-->16.49
16.482-->16.48
16.425-->16.43
7.67 --> 7.67 (no conversion)
I can use the below C# method to convert the values
Math.Round(16.482*20)/20;
But this method not works for me, it gives the following results
16.489-->16.5
16.482-->16.5
7.67 --> 7.7
16.425-->16.45
whats the elegant way in c# to do this.
Math..::.Round Method (Decimal, Int32, MidpointRounding)
Rounds a double-precision floating-point value to the specified number of fractional digits. A parameter specifies how to round the value if it is midway between two other numbers.
Math.Round(1.489,2,MidpointRounding.AwayFromZero)
Did you try
Math.Round(16.482*200)/200;

Categories

Resources