IEEE floating point support

[Thomas M. Breuel]

|	While it's possible to make do with function calls and 
|imperatives to optimizers to reverse-engineer the programmer's intent -
|Fortran and C prove that programmers can make do with just about anything -
|generally it's a lot easier to write as you think and think as
|you write.

It has nothing to do with "reverse engineering". Function call
syntax or operator syntax are equivalent for invoking some
language primitive from the compiler's point of view.

|So I prefer an operator notation
|for comparisons. The most natural would be something like
|	if (x <? y) 
|where the relational operator is a list of relations chosen from < = > ?
|with ? standing for unordered.   This corresponds to what happens at the
|lowest levels of the hardware.

These new "natural" comparison operators have some truly unnatural
properties (for comparison operators). For examples, (x!<=y) && (x!>=y) 
can be true.

In short, my reasons for disliking the proposed new operator syntax for
IEEE arithmetic are:

 * it forces compiler vendors to change their compilers and debuggers;
   on the other hand, function syntax for the same features can be
   implemented as macros, function calls, or compiler builtins,
   whichever is most convenient. Most of the IEEE features can, in
   fact, easily be implemented using macros or functions.

   In particular, if function/macro syntax is used, people who have old
   compilers can compile new code by including a simple header file;
   they don't need to get a new version of the compiler.

 * the proposed set of operators do not clearly enough alert the
   reader that this section of numerical code deals with something 
   special or exceptional; code like:

   #include <ieeestd.h>

	if(isnan(x) || isnan(y) || x<y) {...}

	if(IEEE_COMPARE(<,x,y)) {...}

	if(IEEE_COMPARE(IEEE_LT|IEEE_UN,x,y)) {...}

   draws much more attention than something like:

	if(x!>=y) {...}

   NaN's are something quite pathological, and they shouldn't be
   handled simply by slipping in a "!" here and deleting an "="
   there.

 * it would add a significant number of new operators to the C
   programming language, possibly complicating the precedence rules and
   making C source code look even more like line noise; in addition,
   these new operators would have to be supported for other numerical
   types (since they are in analogy to "!="), and, in particular, they
   would have to be supported by writers of numerical classes in C++.

 * it would somehow give IEEE floating point a distinguished status
   among floating point models for C; C doesn't even have special
   provisions for ASCII, why should it have special provisions for
   IEEE floating point? (Of course, it makes sense to provide standard
   bindings for IEEE floating point, but to augment the syntax of
   the language to accomodate IEEE is going a little too far.)

 * I personally don't agree that "x!>=y" is more "natural" than
   an explicit test for NaN's; if anything, I think it's less
   natural.

I agree that it is important to provide standard bindings for IEEE
floating point features in C, but function syntax seems the better
way of doing this.

					Thomas.