What logic works behind the rounding off of floating point number in c language?

Question

I have written a program in c language to roundoff floating point number but the output of the program does not follow any logic. The code is-->

#include<stdio.h>

int main(){
    float a=2.435000;
    float b=2.535000;
    float c=2.635000;
    float d=2.735000;
    float e=2.835000;
    //Rounding off the floating point numbers to 2 decimal places
    printf("%f  %.2f\n",a,a);
    printf("%f  %.2f\n",b,b);
    printf("%f  %.2f\n",c,c);
    printf("%f  %.2f\n",d,d);
    printf("%f  %.2f\n",e,e);


    return 0;
}

OUTPUT:

2.435000 2.43

2.535000 2.54

2.635000 2.63

2.735000 2.73

2.835000 2.84

All the floating numbers have same pattern of digits i.e. they are in the form of 2.x35000 where x is different in different numbers. I am not getting why they are showing different behaviour while getting roundoff ,either they should give 2.x3 or 2.x4 but for different x it is giving different value.

What is the logic behind this?

You are assuming the numbers are accurately represented in the first instance. If they are inaccurately represented then you are getting a roundoff for *both* the outputs of each, one to 6 places and one to 2 places. — Weather Vane, Jul 21 '21 at 17:58
Change your `%f` specifiers to something like `%.9f` and the [weirdness of floating point](https://stackoverflow.com/q/588004/10077) becomes more apparent. — Fred Larson, Jul 21 '21 at 18:01
Please see [Is floating point math broken?](http://stackoverflow.com/questions/588004/is-floating-point-math-broken) and [Why Are Floating Point Numbers Inaccurate?](https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate) — Weather Vane, Jul 21 '21 at 18:03

Steve Summit · Accepted Answer · 2021-07-21T19:40:19.590

It looks to you and me like 2.435 is a nice, round decimal fraction.
It looks to you and me like if we rounded it to two places, we'd get 2.44.
But most computers do not use decimal fractions internally, and the ones you and I use definitely do not. They use binary fractions, and binary fractions can be surprising.

Internally, it turns out that the number 2.435 cannot be represented exactly in binary. As a float, it's represented internally as a binary fraction that's equivalent to 2.434999942779541015625. That's pretty close to 2.435, but you can see that if you round it to two places, you get 2.43 instead.

The same sorts of argument explain your other results. 2.635 is really 2.6349999904632568359375, so it rounds to 2.63. But 2.535 is 2.5350000858306884765625, so it rounds to 2.54, as you expect.

Why can't we get closer to, say, 2.435? As I said, internally it's a binary fraction equivalent to 2.434999942779541015625. The actual IEEE-754 single-precision representation is 0x401bd70a, which works out to 0x0.9bd70a × 2², or 0.60874998569488525390625 × 2². But if we "add 1" to it, that is, if we make it the tiniest bit bigger that we can, the next float value is 0x401bd70b, which is 0x0.9bd70b or 0.608750045299530029296875 × 2², which is 2.4350001811981201171875, which ends up being a little bit farther away from 2.435. (It's actually over three times as far away. The first number is off by 0.000000057; the second one is off by 0.000000181.)

You can read more about the sometimes surprising properties of binary floating-point numbers at these other "canonical" SO questions:

Two other interesting questions that were asked about them -- just in the past couple of days -- were:

What logic works behind the rounding off of floating point number in c language?

1 Answers1