Page History

The C programming languages provide the ability to use floating-point numbers for calculations. C99 specifies an overall library that requirements on a conforming implementation needs to follow for floating-point numbers , but makes few guarantees about the specific underlying floating-point representation . Because because of the preexistence existence of competing floating-point systems, C99 uses intentionally vague language when dealing with the requirements of floating point values.

By definition, a floating-point number is of finite precision and, and regardless of the underlying implementation, is prone to errors associated with rounding (see FLP01-C. Take care in rearranging floating point expressions and FLP02-C. Consider avoiding floating point numbers when precise computation is needed).

Though a fully conforming implementation is free to create its own floating point system, there is a standard which garners overwhelming popularity in most systems, and another which used to be popular in many older systems. The most popular implementation, used by the default options of Microsoft Visual Studio and GCC on Intel architectures, is IEEE 754. The second, considered legacy, is known as the "IBM floating point representation" or sometimes as "IBM/370." Each of these systems have The most common floating-point system is specified by the IEEE 754 standard. An older floating-point system is the IBM floating-point representation (sometimes referred to as IBM/370). Each of these systems has differing precisions and ranges of representable values. As a result, they do not represent all of the same values, are not binary compatible, and have differing associated error rates.

Because of a lack of guarantees on the specifics of the underlying floating-point system, no assumptions may be made about either precision or range. Even if code is not intended to be portable, the chosen compiler's behavior must be well understood at all compiler optimization levels.

Here is a simple illustration of precision limitations. The following code prints the decimal representation of 1/3 , to fifty 50 decimal places. Ideally, it would print fifty 3's50 numeral 3s.

#include <stdio.h>

int main(void) {
  float f = 1.0 / 3.0;
  printf("Float is %.50f\n", f);
  return 0;
}

...

Additionally, compilers may treat floating -point variables differently under different levels of optimization \[[Gough 2005|AA. C References#Gough 2005]\].

double a = 3.0;
double b = 7.0;
double c = a / b;

if (c == a / b) {
  printf("Comparison succeeds\n");
} else {
  printf("Unexpected result\n");
}

On a test When compiled on an IA-32 Linux machine with GCC Compiler Version 3.4.4 this code prints:

Unexpected result

When compiled at optimization level 1 or higher or on a test IA-32 Windows XP machine with Microsoft Visual C++ Express 8.0 or on a test , this code prints:

Comparison succeeds

On an IA-32 Linux machine with GCC Compiler Version 3.4.4 with the -O option optimization turned off, this code prints:

ComparisonUnexpected succeedsresult

The reason for this behavior is that Linux uses the internal extended precision mode of the x87 floating -point unit (FPU) on IA-32 machines for increased accuracy during computation.  When the result is stored into memory by the assignment to {{c}}, the FPU automatically rounds the result to fit into a {{double}}. The value read back from memory now compares unequalunequally to the internal representation, (which has extended precision), which is typically an unexpected result.  Windows does not use the extended precision mode, so all computation is done with double precision, and there are no differences in precision between values stored in memory and those internal to the FPU.  OnFor Linuxgcc, compiling withat optimization the {{\-O}} optimization flaglevel 1 or higher eliminates the unnecessary store into memory, so all computation happens within the FPU with extended precision \[[Gough 2005|AA. C References#Gough 2005]\].

...