Thread: Just curious about a strange run-time error using the round function

Sadly, Terrance doesn't know what he's talking about. Anyway....

This has nothing to do with the fround function. If you take it out you will get the same behaviour.

You need to understand the difference between precision and range. Although you can store a number like 100000000000000000000000000000 in a float, that doesn't mean that all of the bits are actually stored (remember that it's stored in binary). In fact, only 24 bits are stored (23 explicity, 1 implicity), another 8 bits are used to store the binary exponent, and 1 bit stores the sign. So if you put that number in a float and then print it, you get 100000001504746621987668885504.000000. So it only stores about 8 decimal digits of precision at most.

In your example, although 797979 fits within the precision of a single-precision floating point value, when you multiply it by 100 it no longer fits. So when you divide it by 100 again you end up with an approximation of the original value.

It actually happens with about 20% of numbers between 167773 and 999999, for example, as you can see in the following program.

Code:

#include <stdio.h>
#include <math.h>

#define LOW  167773.0f
#define HIGH 999999.0f

int main ()
{
    float f, g;
    int cnt = 0;
 
    for (f = LOW; f <= HIGH; f++) {
        g = f * 100.f;
        if (f != g / 100.f)
            cnt++;
    }

    printf("%d / %.0f = %f\n", cnt, HIGH-LOW, cnt/(HIGH-LOW));

    return 0;
}

EDIT: Precision doesn't mean "precision after the decimal". It's just the number of bits stored to represent the value. In essence they are all "after the decimal" (except for the implied leading bit).

Originally Posted by Vladimir Pewton

Wow thanks for you time! I think my understanding of this topic is way better now. I wanted to see why since I multiplied it by 0.01 instead of dividing, and I got the right answer. So I changed the if statement to have g * 0.01 instead, and I got that it failed about 10% of the time. Thank you for answering my question and showing me this small program.

The difference between multiplying by 0.01 instead of dividing by 100 is that 100 can be represented exactly whereas 0.01 can't (since it's stored in binary). So you get different results.

Here's a program that displays the representation of a float. It prints the sign bit, the eight exponent bits (and the decimal value of the exponent in parentheses), and the 24 significand bits (where the leading bit before the binary point is the implied bit, meaning it is not actually stored).

Code:

#include <stdio.h>

typedef unsigned char byte;

#define putbit(b, m) putchar(b & m ? '1' : '0')

void print_float_bits(float f) {
    byte *p = (byte*)&f;    // pointer to bytes
    byte m = 0x80;          // bit mask
    unsigned exponent = 0;

    // sign bit
    putbit(p[3], m);
    putchar(' ');

    // exponent
    for (m >>= 1; m; m >>= 1) {
        exponent = (exponent << 1) | !!(p[3] & m);
        putbit(p[3], m);
    }
    m = 0x80;
    exponent = (exponent << 1) | !!(p[2] & m);
    putbit(p[2], m);
    printf(" (%d)", (int)exponent - 127);

    // significand
    printf(" %c.", exponent != 0 && exponent != 255 ? '1' : '0');
    for (m >>= 1;  m; m >>= 1) putbit(p[2], m);
    for (m = 0x80; m; m >>= 1) putbit(p[1], m);
    for (m = 0x80; m; m >>= 1) putbit(p[0], m);
    putchar('\n');
}

int main() {
    float f;
    while (printf(">>> "), scanf("%f", &f) == 1) {
        printf("%e\n", f);
        print_float_bits(f);
    }
    putchar('\n');
    return 0;
}

Example run:

Code:

>>> 100
1.000000e+02
0 10000101 (6) 1.10010000000000000000000
>>> .01
1.000000e-02
0 01111000 (-7) 1.01000111101011100001010

It seems like student and teacher need to head over to What Every Computer Scientist Should Know About Floating-Point Arithmetic