CRI comments on 92-001 (FPCE)

[Tom MacDonald]

  From:		Tom MacDonald -- Cray Research Inc.

  Subject:	CRI's comments on X3J11.1/93-001

  Vote:		No with comment

Cray Research does not support the forwarding of document X3J11.1/93-001
dated Jan.  20, 1993 to be sent to our parent committee, X3J11, for the
reasons listed below.  If these issues are addressed to our satisfaction,
we will change our position and vote Yes.

1) Pragmas

It is a mistake to specify any pragmas in this document. They cannot be
used in macros and are intended for implementation specific needs. One
possibility is introduce new macros that accept ON/OFF/DEFAULT arguments
and expand into implementation specific directives or keywords.  This can
be hidden in a header file such as the proposed <fp.h> header.


2) New relational and equality operators

The proposed new relational operators are of questionable utility. These
operators are: !<>=, <>, <>=, !<=, !<, !>=, !>, and !<>.  These new
operators are intended to provide additional support for NaNs.  However,
the `isnan' macro in conjunction with the equality operators (== and !=)
are more than adequate for NaN support.  For example:

	isnan(X)  /* means X is a NaN     */
	X!=X      /* means X is a NaN     */
	X==X      /* means X is not a NaN */

The most common coding style is to check a function's arguments upon
entry, and if any are NaNs, error processing occurs.  There is
insufficient justification for adding all of these new operators.

In contrast the addition of the new operators makes C a more complicated
language.  This proposal more than doubles the number of relational and
equality operators.  The following table shows how much the complexity of
comparisons increases with these new operators.


	   Standard C Comparisons
	   ----------------------


	       less    equal   greater
	<       T        F        F
	<=      T        T        F
	>       F        F        T
	>=      F        T        T
	!=      T        F        T
	==      F        T        F



	   Proposed IEEE Comparisons
	   -------------------------


	       less    equal   greater  unordered
	<       T        F        F        F
	<=      T        T        F        F
	>       F        F        T        F
	>=      F        T        T        F
	!=      T        F        T        T
	==      F        T        F        F
	!<      F        T        T        T
	!<=     F        F        T        T
	!>      T        T        F        T
	!>=     T        F        F        T
	!<>     F        T        F        T
	<>      T        F        T        F
	<>=     T        T        T        F
	!<>=    F        F        F        T


The number of possible comparisons increases from 18 to 56.

Another issue is the precedence of the new operators.  The proposal
states that they have the same precedence as the relational operators
when clearly some of the new operators are more closely tied to equality
operations (e.g., !<>).  This only emphasizes that the new operators
obscure the meaning of the terms `equality' and `inequality' thereby
making algorithms less clear.

A final issue is that the use of some of these new operators with integer
and pointer types is nonsensical (i.e., !<>= and <>=).  The non-symmetric
nature with respect to types is both confusing and troubling.


5) Types and portability of code

The proposal states:

"The long double type should have strictly more precision than double
 which should have at least twice the number of digits of precision as
 float.  If not, the implementation should emit a warning when processing
 a translation unit that uses distinct floating types with the same
 precision."

Even though this is only a "should", we think it is an unnecessary and
misleading suggestion.  It is unnecessary because as long as the types
used have at least the minimum amount of precision required by the
algorithm, the result will be accurate to within the ability of the type
to represent the true result.  Forcing the distinct types to have
different amounts of precision does not contribute to the accuracy.  And
it is misleading because it suggests that code will be completely portable
(that is, give the exact same results) between all implementations that
conform with the proposed standard.  This is not true.  The document is
riddled with "implementation defined" specifications.  Almost any of these
open the door for slightly different results in different implementations.
So either all aspects of precision and evaluation methods have to be
precisely and unambiguously defined and required or the goal of absolute
portability must be forgotten.  It is not realistic to force all
implementations to just one hardware model, therefore, variations in
results must be expected.