Varying Floating-Point Precision

Varying Floating-Point Precision

William Smith

William Smith is the engineering manager at Montana Software, a software development company specializing in custom applications for MS-DOS and Windows. You may contact him by mail at P.O. Box 663, Bozeman, MT 59771-0663.

Most C compilers support two different floating-point (real number) representations, the types loat and double. Some compilers, such as Microsoft C/C++ (MSC) and Borland C++ (BC), support a third type long double.

The choice of which floating-point type best matches an application's requirements for real number representation frequently confronts the programmer. Traditionally, the most popular choice and default floating-point type has been the type double. This type is not necessarily the best choice, however. An embedded application may be space limited, putting a premium on the small size offered by the loat type. Another application may require extremely high accuracy, putting a premium on the high precision sometimes offered by the long double type.

The three different real number types represent a broad choice. There are significant tradeoffs between them. The differences in size are obvious. On a PC, the loat type is four bytes, double is eight bytes, and long double is ten bytes. For situations where a program stores large amounts of data in memory as arrays or matrices, or on disk in binary files, the space savings of using float can be substantial.

Determining the effects on accuracy caused by the differences in precision between the three types is less obvious. Testing of an actual application helps expose differences in accuracy. Table 1 lists the sizes and precision of the floating-point types, in terms of significant decimal digits and a factor called epsilon. Epsilon is the smallest number that, when added to the value 1.0, creates a new number that is greater than 1.0.

High precision does not guarantee high accuracy or correctness. Accuracy is not the same as precision. A type has fixed precision, but each computed value can have different accuracy. Accuracy depends not only on precision but on what a program does with a particular value of a floating-point type.

Besides size and accuracy, the floating-point types also differ in how they affect the performance of a program. The effects on speed are even less obvious than accuracy, and usually require some testing.

The ideal way to measure the differences between the three types is to create different precision versions of the same program. With a small amount of effort, you can write your application, or modify an existing application, so the floating-point type is changeable at compile time. What better way to determine the effects on an application of using different floating-point types then by exercising different precision versions of the same program?

This article presents some techniques you can employ to change the choice of floating-point types at compile time. A single include file, real_t.h, shown in Listing 1, does all the needed preprocessor gymnastics to make different precision versions of the same application.

The techniques employed by real_t.h are limited to choosing among the standard predefined types. If you need a different type than the standard ones, my suggestion is to create new types using C+ +. With some effort, you can create anything from a two-byte real to a BCD (binary-coded decimal) math package. Creating a new type using C+ + affords complete control over the size and the implementation details of the math it employs.

Redefining Types

#define double float

Another way is to use a generic floating-point type that is set at compile time:

typedef float real_t;

The include file real_t.h supports a combination of both approaches. It creates a generic type, real_t. It will also redefine float, double, and long double to real_t unless you specify that your code uses more than one type (mixed precision). For example, when setting the generic floating-point type to float, real_t.h does the following:

typedef float real_t;
#define double real_t;
typedef long double long_double;
#define long_double real_t;
#define long

Effects on <math.h>

In addition to ensuring that the proper precision version of a particular function is called, macros wrappers for all the functions in <math.h> yield an opportunity for embedding debugging code in an application. (See "Debugging with Macro Wrappers", CUJ, October 1992.) Pinpointing what line of source code caused a floating-point exception is easy by using the predefined macros __FILE__ and __LINE__, along with parameter checking of the standard math functions.

You can also make safe versions of the standard math functions by checking for out-of-range parameters. One fixup for such a parameter is to substitute a default result that is in range. This will hide the problem, of course. But you can also trap the error and report it, then use such a substitution to recover gracefully.

Effects on <float.h>

Manifest Constants

To prevent conversion and possible loss of accuracy, the precision of manifest constants should match the precision of any floating-point variables that use them. Casting constants upon assignment may eliminate a compiler's warning that a conversion is taking place, but it does not ensure the program stored the constant in the program file the way you may desire. For example,

long double x = (long double)0.1;

long double x = 0.1L;

#define RC( x ) ( x##F )

#define RC( x ) ( x##L )

In a similar fashion, you may wish to define a format code for the printf family of functions. This format code would change based upon the precision of the generic type real_t.

Parameter Passing

Most of the time this behavior does not matter and is hidden from the programmer. About the only time this will become a concern is when you are creating a dynamic link library (DLL) for Microsoft Windows and are exporting functions from the DLL that return floating-point types. Since DLLs have a different data segment than the calling application, but share the same stack, there can be a bit of confusion. It can be hard to guess, for example, what segment the hidden pointers point to, or contains the floating point accumulator, or contains the NDP stack. The best way to avoid problems for Windows DLLs that export functions returning floating-point types is to use _pascal calling convention and the large memory model.

Using real_t.h

#include "real_t.h"

real_t.h reacts to and modifies its behavior in response to six different constants. You can define these constants on the compiler command line or inside your program. Either way, you must define them before you program includes the file real_t.h. The first three are REAL_????, where ???? is either FLT, DBL, or LDBL. These three constants control what the default floating-point precision is. REAL_FLT is float, REAL_DBL is double, and REAL_LDBL is long double. If an application does not define one of these three constants and still includes real_t.h, REAL_DBL is assumed. This results in designating double as the default floating-point type real_t.

The constant REAL_MP determines if existing standard types get redefined. If you define REAL_MP, your program desires mixed precision. The existing standard types do not get redefined to the desired floating-point type. Defining REAL_MP also prevents the constants in float.h from getting redefined.

The constant REAL_NL controls whether the standard keyword long gets redefined. To convert the long double type to another type requires defining long to nothing. If you define REAL_NL and do not define REAL_MP, then long gets defined to nothing.

/* kludge for long double */
#if defined ( REAL_NL ) && !defined ( REAL_MP )
#define long
#endif

Comparing Precisions

Table 2 summarizes the results of running Listing 2 for float, double, and long double types. Table 3 lists similar results for running Listing 3.

I compiled the programs using MSC with the compiler options

/FPi87 /0d /DREAL_????

For both Listing 2 and Listing 3, the error value represents the accumulated error due to lack of accuracy. Ideally, the error should be 0.0. For simplicity and to facilitate timing, I obtained the value of error using a debugger instead of using printf.

The time is in seconds. Times are for testing on a 20MHz 386 with a math co-processor. Smaller numbers represent faster better performance.

Speed

My interpretation of the results is that the larger the size the more overhead in basic assignment operations. Listing 2 emphasizes simple operations and asassignments. The float version is the fastest because floats are smaller, resulting in less physical memory being pushed around.

In the case of Listing 3, the long double version is the fastest. This is due to the fact that long double is the native type for the math co-processor. Using the native long double when calling the math functions eliminates the need to convert from one type to another. Type float is the slowest because the program must not only repeatedly convert from long double to double but also from double to float. Consequently, a program that makes a lot of use of the math functions in <math.h> may see some speed improvement with the long double type.

I base these conclusions solely upon the data generated by Listing 2 and Listing 3. To get a clear perspective on how a specific compiler treats different types would entail disassembling the compiled code.

Accuracy

The same is true for the long double type compared to the double or the float. The difference in magnitude is about the same as the difference in magnitude between LDBL_EPSILON and DBL_EPSILON or FLT_EPSILON. In the case of Listing 2, accuracy is directly related to precision.

This relationship does not hold true for Listing 3. Listing 3 tests the accuracy of one of the math functions, sqrt. I am tempted to conclude that the loss of accuracy in Listing 3 occurs mainly in the sqrt function and in any type conversion in calling the sqrt function. Hence, the differences between the error results are due to the differences between the two functions sqrt and sqrtl. Since there is not a float version of the sqrt function, both the float and the double version use the same function, sqrt. It is not surprising then that the corresponding versions generated the same amount of error.

The long double type has its own function sqrtl. It would be interesting, from the standpoint of both accuracy and speed, to see the effect of using the long version with the other precisions. In the case of Listing 3, accuracy did not improve when going from type float to the higher precision type double. It did improve by going to the long double type.

Conclusions

Fortunately, imperfect accuracy is "good enough" most of the time. And for situations that require varying "goodness," there are three different floating-point types in C that one can use. Deciding which type is the best match for a specific application requires an assessment based upon the size, speed, and accuracy needs of the application.

The best way to determine what type is best is to test different precision versions of an application. The include file real_t.h provides the tools to easily switch floating-point types at compile time. It uses some aggressive and uncommon macro and preprocessor tactics, but it can even help existing applications change precision at compile time.

So instead of just using the default type double, try experimenting your code with the three different floating-point representations that most modern C and C++ compilers offer. There are usually advantages of one type over the others when addressing specific applications needs