• TR Part 1: Designated Initializers and Compound Literals
• TR Part 2: Aliasing Control via Restricted Pointers
• TR Part 3: Floating-Point C Extensions

I covered TR Part 1 and TR Part 2 in my last column. This month, I review the much more extensive TR Part 3. Floating-point arithmetic is a boundless pit of subtleties and complexities. Floating-Point C Extensions is a measured attempt to bring to heel a few more of those subtleties and complexities within the compass of the C programming language.

That Standard was not lovingly received in all circles. You have to understand that, up to that time, each hardware vendor traditionally defined a unique floating-point format. The accompanying arithmetic was equally idiosyncratic. Some vendors favored speed over precision, some favored simplicity of implementation above all else. In fairness, all floating-point implementations had improved over the years, as better techniques became well known. But vendors still had a stake in continuing to support their proprietary approaches.

You also have to understand that floating-point arithmetic takes a lot of microcode. In fact, it typically takes about as many kilobytes to describe the floating-point instructions as it does all the rest of the instruction set put together. (And that's why floating-point was often optional on minicomputers, or is still sold separately as a coprocessor with microcomputers.)

So along comes this Standard that is perhaps twice as complex as your typical floating-point architecture of yore. It obsoletes everything that has gone before and causes conversion problems in the bargain. You can see why not everyone jumped aboard the bandwagon.

A few important players did, however. Most notable were Intel, with their 80X87 line of floating-point coprocessors, and Motorola, with their MC 68881. They turned a paper document into very real, and affordable, hardware. And they forced the world to give serious consideration to this new, more conscientious, approach to computing in floating-point.

Today, all but the oldest architectures generally offer some variant of IEEE 754 floating-point arithmetic. I say variant in part because the Standard does offer some latitude in the choice and representation of data representations, and in the range of operations supported. But I also mean that not everybody slavishly implements all of the requirements of the Standard. (I certainly didn't, in the several software versions I put on the market in years past.) And some people try to match the Standard, but ship products with various errors and inaccuracies. Don't think you're in safe territory just because a vendor offers IEEE 754 compliance.

I should also mention ANSI/IEEE 854-1987, IEEE Standard for Radix-Independent Floating-Point Arithmetic. That document extends the floating-point model to bases other than 2. While in some ways it is now a more fundamental document than IEEE 754, it has so far had less practical effect.

We on committee X3J11 listened to several presentations on the existing floating-point standards. We also got knowledgeable input from several vendors of alternate floating-point formats. Tom MacDonald of Cray Research did quite a bit of work along these lines for the committee. In the end, I believe we did far more than we had to, and far less than we could have.

We cribbed the abstract description of floating-point formats from the FORTRAN Standard. That was written in the heyday of proprietary floating-point standards, so it was quite general. We agreed on various minima for precisions and exponent ranges, then expressed them in terms of the FORTRAN model. Somewhere along the way, we decided to add the third floating-point type, long double. We chose, however, not to require that it be represented any differently than double.

Tom MacDonald championed the view that sophisticated numerical programmers needed to know about the model parameters chosen by each implementation. Yes, there are programs that play clever games with a computer long enough to figure out these parameters. But it seemed perverse to require such antics to get answers so easily supplied by an implementation.

Thus was born the header <float.h>. It can be subtitled, "Everything you always wanted to know about your floating-point processor, but were afraid to ask." From personal experience, as both a compiler implementor and a numerical programmer, I'd add the trailer, "and then some." I have found uses for only a handful of the parameters we chose to put in that header. Still, I'm glad they're there.

As for IEEE 754, we listened carefully, but we didn't feel an obligation to follow the bandwagon. (IBM, DEC, and Cray would have screamed rather loudly if we'd tried.) We aimed for reasonable compatibility with the basic representations, but we didn't mandate all the error codes or extended capabilities in that standard. It is fairest to say that we made the C Standard tolerant of IEEE 754 peculiarities. And that was enough to make ANSI happy.

• to give more C language support for floating-point operations in general
• to give reasonably complete C language support (called a "C binding" these days) for IEEE 754 floating-point operations in particular

Four of the pragmas loosen the usual C rules about honoring the types declared by the programmer:

#pragma fp_wide_function_returns { on off }
#pragma fp_wide_function_parameters { on off }
#pragma fp_wide_variables { on off }
#pragma fp_contract { on off }

• permit functions to return a wider floating-point type than declared
• permit functions to receive (and not narrow down) arguments with wider floating-point types than declared
• permit objects to be represented as wider floating-point types than declared
• permit the use of "contracted" instructions, such as combined multiply-add, even when the result is slightly different than when not contracted

Sounds good. So why would you not want to do this all the time? Because some programs actually depend on truncation of precision to behave properly. (This is generally more true when narrowing integers than when narrowing floating-point values, however.) And some programs have large arrays of floating-point values. They depend on trading precision for storage space to work properly in limited storage. Thus the pragmas.

The fifth pragma is part of the IEEE 754 support:

#pragma fenv_access { on off default }

#define_MIN_EVAL_FORMAT {0 1 2}
#define_WIDEST_NEED_EVAL{0 1}

• whether the narrowest kind of floating-point arithmetic is performed in float (0), double (1), or long double (2)
• whether the kind of floating-point arithmetic for a subexpression is determined by the wider of the two operands (0), or by the widest kind that will be needed for the containing expression (1)

The C Standard makes a few blanket statements about writing floating-point constants and folding constant expressions. The Technical Report goes into considerably more detail about what's expected. In particular:

• constant folding that can occur at runtime, and that causes a floating-point exception, must result in an expression that reports the exception at runtime
• any number of "identities" of mathematics cannot be used in constant folding, because they are not identities in the real world of floating-point arithmetic

#define FLT_MAX 0x. 7F7FFFFF

The Technical Report offers another alternative. It adds a slew of new relational operators, and redefines an existing one, to handle the unordered case properly inline. The basic idea is that a ! can be put in front of any of the relational operators that don't already have one. Its presence now usually means, "also true if unordered." Thus, != is redefined to mean, "unordered, less, or greater." Its old meaning is now handled by the new operator <>. There is also a new operator <>= which means, "less, equal, or greater" (believe it or not).

I won't list all the operators, or discuss them in detail, because I get a headache every time I think about them. I doubt that I'll ever have occasion to use such creatures, given library functions that perform the same tests more readably.

• __FPCE__ is defined if this Technical Report is implemented.
• __FPCE_IEEE__ is defined if IEEE 754 compatibility is also present.

The functions in <stdlib.h> that convert from text to floating-point types have to be smarter. First, the old warhorse atof is no longer excused from proper error checking. Then there are new functions strtof, to convert directly to float, and strtold, to convert to long double. And then there are new requirements on all these functions plus the older workhorse strtod. All must now accept text strings such as INF and NAN for the funny codes.

Their companions in <stdio.h> that read such numbers are, of course, the scan functions — fscanf, etc. These get smarter too, since their behavior is defined in terms of strtod anyway.

Their opposite numbers are the print functions — fprintf, etc. They are now expected to print the same codes for infinities and NaNs. They also get three new conversion specifiers:

• %a, to print in the new hexadecimal floating-point format
• %A, the same as %a, only using upper case letters instead
• %F, the same as %f, only using upper case letters instead

I end with one of my favorite quotes from R.W. Hamming. He said it of an early book of floating-point arithmetic, but it applies at least as well here: "Nobody should have to know that much about floating-point arithmetic, but I'm afraid sometimes you might."