Questions about NCEG

[Richard A. O'Keefe]

In article <8949 at celit.fps.com>, ps at fps.com (Patricia Shanahan) writes:
> Arbitrarily treating relational operations between unordered floats as
> returning false is certainly one way of handling them. Because of exactly
> the point you make about the difference between x>y and !(x<=y) I do not
> consider it a truly logical solution.

This is still bashing IEEE 754 for something it does not do.

Let me quote section 5.7 of the IEEE 754 standard:

	It shall be possible to compare floating-point numbers in all
	supported formats, even if the operands' formats differ.
	Comparisons are exact and never overflow nor underflow.
	Four mutually exclusive relations are possible:  less than,
	equal, greater than, and unordered.  The last case arises
	when at least one operand is NaN.  Every NaN shall compare
	unodered with everything, including itself.  Comparisons shall
	ignore the size of zero (so +0 = -0).
	The result of a comparison shall be delivered in one of two
	ways at the implementors option:  either as a condition code
	identifying one of the four relations listed above, or as a
	true-false response to a predicate that names the specific
	comparison desired.  In addition to the true-false response,
	an invalid operation exception (7.1) SHALL be signalled
	when, as indicated in Table 4, last column, unordered
	operands are compared [using <, >, <=, or >=].   Implementations
	that provide predicates SHALL provide the first six predicates
	in Table 4 [= and != do not signal exceptions for NaNs, but NaNs
	are never equal to anything, so #define isNaN(x) ((x) != (x));
	<, >, <= and >= SHALL signal exceptions for NaNs] and SHOULD
	provide the seventh [ x ? y = x, y, unordered = isNaN(x)||isNaN(y)],
	and a means of logically negating predicates.

Note that this invalid operation exception is one where it is _impossible_
to deliver a quiet NaN.

> I think my own preference would be to treat unordered comparison as an error
> and trap it, unless the program (through some new high level language
> construct) indicated what should be done with the unordered case. For example,
> one could add an additional clause to the traditional if-then-else, with the
> option of combining the additional clause with one of the cases.

No new construct is needed.
#ifdef	IEEE
#define	isNaN(x) ((x) != (x))
#define	unOrd(x,y) (isNaN(x) || isNaN(y))
#else
#define	isNaN(x) ((x),0)
#define	unOrd(x,y) ((x),(y),0)
#endif

	if (unOrd(x,y)) {
	    /* either x or y is NaN */
	} else
	if (x > y) {
	    /* x > y; neither is NaN */
	} else {
	    /* x <= y; neither is NaN */
	}

> Although I am interested in whether it is possible to construct a set of
> extensions to a high level language that will provide truly consistent,
> logical, support for IEEE 754, I am still very dubious about whether the
> number of programs that would benefit would be sufficient, compared to
> the number for which taking a trap and core dump at the first arithmetic
> exception would be the right solution, to justify the effort.

What effort?  Let your hardware be IEEE-ish (that is to say, accurate)
except for always signalling exceptions.  Surely you would like to have
an exception-handling mechanism which lets you substitute an answer and
continue (e.g. BSD signals).  That's all you need.  The classical
example (it's in Apple's SANE book, for example) is continued fraction
evaluation:  there are ways of organising the calculation which give you
good accuracy but would be simpler if 1/(1/0)) were 0.

Obviously, little or no _pre_-IEEE754 code would benefit, precisely
because it was written for arithmetic systems which didn't have features
like gradual underflow (that's the one _I_ like; at last an arithmetic
system where (x-y == 0) implies (x == y)) or infinities.  And the fact
that it is possible to write "self-checking" code in an IEEE 754 system
(compute the same thing twice with rounding set differently and see how
different the answers are) is something worth having.

-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."