Dodging the inaccuracy of a floating point number

Question

I totally understand the problems associated with floating points, but I have seen a very interesting behavior that I can't explain.

float x = 1028.25478;
long int y = 102825478;
float z = y/(float)100000.0;
printf("x = %f ", x);
printf("z = %f",z);

The output is:

x = 1028.254761 z = 1028.254780

Now if floating numbers failed to represent that specific random value (1028.25478) when I assigned that to variable x. Why isn't it the same in case of variable z?

P.S. I'm using pellesC IDE to test the code (C11 compiler).

Your code [prints the same thing for me](https://ideone.com/9zyYyF). — Sergey Kalinichenko, Dec 21 '17 at 15:11
This isn't the duplicate. I think there are several actual duplicates, but they are hard to find. Basically, the compiler performs math as `double` in the second case. — Sergey Kalinichenko, Dec 21 '17 at 15:15
Reopened. This is a type conversion issues, not a floating point issue per se. — Bathsheba, Dec 21 '17 at 15:17
I had a similar question not too long ago (albeit in a different context). See [this answer](https://stackoverflow.com/a/47066540/7159784) that I got. Also read the comments on the question for a deeper understanding. — Nik, Dec 21 '17 at 15:34
The question seems to presuppose some false premises. The biggest is that the float value obtained by converting the `long int` 102825478 to type `float` is precisely 100000 times larger than the `float` constant 1028.25478. Even if that were true, the assumption that floating-point division of the former by 100000 would then yield exactly the latter is also unsafe. — John Bollinger, Dec 21 '17 at 16:15
@JohnBollinger the case is that why does it *print `1028.25478`* when `float = 1028.25478;` clearly truncates to `1028.254761`. — Antti Haapala -- Слава Україні, Dec 21 '17 at 16:23
Priniting using %.10f : x = 1028.2547607422 z = 1028.2547800000 — Ahmed Soliman, Dec 21 '17 at 16:24
How is `1028.254761` rounded to `1028.25478`, that is not the nearest float value. — Antti Haapala -- Слава Україні, Dec 21 '17 at 16:27
@JohnBollinger the next `float` from `1028.2547607421875` is `1028.25` **`50048828125`** — Antti Haapala -- Слава Україні, Dec 21 '17 at 16:31

Antti Haapala -- Слава Україні · Accepted Answer · 2017-12-21T15:36:52.820

I am pretty sure that what happens here is that the latter floating point variable is elided and instead kept in a double-precision register; and then passed as is as an argument to printf. Then the compiler will believe that it is safe to pass this number at double precision after default argument promotions.

I managed to produce a similar result using GCC 7.2.0, with these switches:

-Wall -Werror -ffast-math -m32 -funsafe-math-optimizations -fexcess-precision=fast -O3

The output is

x = 1028.254761 z = 1028.254800

The number is slightly different there^.

The description for -fexcess-precision=fast says:

-fexcess-precision=style

This option allows further control over excess precision on machines where floating-point operations occur in a format with more precision or range than the IEEE standard and interchange floating-point types. By default, -fexcess-precision=fast is in effect; this means that operations may be carried out in a wider precision than the types specified in the source if that would result in faster code, and it is unpredictable when rounding to the types specified in the source code takes place. When compiling C, if -fexcess-precision=standard is specified then excess precision follows the rules specified in ISO C99; in particular, both casts and assignments cause values to be rounded to their semantic types (whereas -ffloat-store only affects assignments). This option [-fexcess-precision=standard] is enabled by default for C if a strict conformance option such as -std=c99 is used. -ffast-math enables -fexcess-precision=fast by default regardless of whether a strict conformance option is used.

This behaviour isn't C11-compliant

That makes a lot of sense to me, but I'm sure that it is C11. — Ahmed Soliman, Dec 21 '17 at 16:20
Also, the CCFlags are: -std:C11 -Tx86-coff -Ot -Ob1 -fp:precise -W1 -Gd — Ahmed Soliman, Dec 21 '17 at 16:21
yeah, so, it must be a case of bad compiler. Can you get the *assembler output* from Pelle's? — Antti Haapala -- Слава Україні, Dec 21 '17 at 16:32

Bathsheba · Answer 2 · 2017-12-21T16:02:17.170

2

Restricting this to IEEE754 strict floating point, the answers should be the same.

1028.25478 is actually 1028.2547607421875. That accounts for x.

In the evaluation of y / (float)100000.0;, y is converted to a float, by C's rules of argument promotion. The closest float to 102825478 is 102825480. IEEE754 requires the returning of the the best result of a division, which should be 1028.2547607421875 (the value of z): the closest number to 1028.25480.

So my answer is at odds with your observed behaviour. I put that down to your compiler not implementing floating point strictly; or perhaps not implementing IEEE754.

edited Dec 21 '17 at 16:02

answered Dec 21 '17 at 15:26

Bathsheba

231,907
34
361
483

1

And of course, C does not require implementations to adhere strictly or even at all to IEEE-754. In practice, though, substantially all implementations for modern, general-purpose platforms in fact do use IEEE-754 formats and at least approximate IEEE-754 semantics. Many *do not* adhere strictly to IEEE-754, at least by default. – John Bollinger Dec 21 '17 at 15:53

chux - Reinstate Monica · Answer 3 · 2017-12-21T19:51:02.473

Code acts as if z was a double and y/(float)100000.0 is y/100000.0.

float x = 1028.25478;
long int y = 102825478;
double z = y/100000.0;

// output
x = 1028.254761 z = 1028.254780

An important consideration is FLT_EVAL_METHOD. This allows select floating point code to evaluate at higher precision.

#include <float.h>
#include <stdio.h>
printf("FLT_EVAL_METHOD %d\n", FLT_EVAL_METHOD);

Except for assignment and cast ..., the values yielded by operators with floating operands and values subject to the usual arithmetic conversions and of floating constants are evaluated to a format whose range and precision may be greater than required by the type. The use of evaluation formats is characterized by the implementation-defined value of FLT_EVAL_METHOD.

-1 indeterminable;
0 evaluate all operations and constants just to the range and precision of the type;
1 evaluate ... type float and double to the range and precision of the double type, evaluate long double ... to the range and precision of the long double type;
2 evaluate all ... to the range and precision of the long double type.

Yet this does not apply as z with float z = y/(float)100000.0; should lose all higher precision on the assignment.

I agree with @Antti Haapala that code is using a speed optimization that has less adherence to the expected rules of floating point math.

Dodging the inaccuracy of a floating point number

3 Answers3