Why is not a==0 in the following code?

#include <stdio.h>
int main( )
{
    float a=1.0;
    long i;

    for(i=0; i<100; i++)
    {
        a 开发者_JS百科= a - 0.01;
    }
    printf("%e\n",a);
}

Result is: 6.59e-07

It's a binary floating point number, not a decimal one - therefore you need to expect rounding errors. See the Basic section in this article:

What Every Programmer Should Know About Floating-Point Arithmetic

For example, the value 0.01 does not have a precise represenation in binary floating point type. To get a "correct" result in your sample you would have to either round or use a a decimal floating point type (see Wikipedia):

Binary fixed-point types are most commonly used, because the rescaling operations can be implemented as fast bit shifts. Binary fixed-point numbers can represent fractional powers of two exactly, but, like binary floating-point numbers, cannot exactly represent fractional powers of ten. If exact fractional powers of ten are desired, then a decimal format should be used. For example, one-tenth (0.1) and one-hundredth (0.01) can be represented only approximately by binary fixed-point or binary floating-point representations, while they can be represented exactly in decimal fixed-point or decimal floating-point representations. These representations may be encoded in many ways, including BCD.

There are two questions here. If you're asking, why is my printf statement displaying the result as 6.59e-07 instead of 0.000000659, it's because you've used the format specifier for Scientific Notation: %e. You want %f for the floating point a.

printf("%f\n",a);

If you're asking why the result is not exactly zero rather than 0.000000659, the answer is (as others have pointed out) that with floating point arithmetic using binary numbers you need to expect rounding.

You have to specify %f for printing the float number then it will print 0 for variable a.

That's floating point numbers rounding errors on the scene. Each time you subtract a fraction you get approximately the result you'd normally expect from a number on paper and so the final result is very close to zero, but not necessarily precise zero.

The precision with floating numbers isn't accurate, that's why you find this result.

Cordially