notes from a conference with Jim Thomas and W. Kahan

[David Hough]

We met on 17 July to discuss some NCEG IEEE issues.  As usual, we covered a 
great deal more.  I made notes of the following major and minor points:

CRAY ARITHMETIC

I was surprised to learn that not all Cray Research computers do arithmetic
the same way.  This may be common knowledge in the Cray world, but the
default subtraction arithmetic is chopped incorrectly on some models and
rounded incorrectly on others.  "Incorrectly" because the round/chop takes
place before normalization of the result.  This introduces subtle 
differences in results.
Kahan has drafted a long paper
for the Cray users group on the costs associated with Cray arithmetic.

LONG DOUBLE == DOUBLE

An NCEG IEEE system which has implemented long double as a synonym for double 
should issue a diagnostic when long doubles are used, since the result is pretty
unlikely to be what the programmer intended.   Since in an NCEG IEEE system
float means IEEE single and double means IEEE double, you wouldn't declare
long double unless you wanted more than double.

!cc CONDITIONALS IN C

Kahan proposes adding !< !<= !> !>= conditionals to C.  You could go further
and add e.g. <? <=? >? >=?.  Among the four possible results of a comparison
(equal, less, greater, unordered), 

< 	
	true on less
	false on equal or greater
	false with invalid exception on unordered
>= 	
	true on equal or greater
	false on less
	false with invalid exception on unordered
<? or !>= 	
	true on less or unordered
	false on equal or greater
>=? or !< 	
	true on equal or greater or unordered
	false on less
!<?
	true on equal or greater
	false on less or unordered
!>=?
	true on less
	false on greater or equal or unordered
?
	true on unordered
	false on less equal greater
!?
	true on less equal greater
	false on unordered	

In other words, ordered comparisons involving NaNs with traditional
operators are always false and raise an invalid exception.
That protects old programs that weren't written with any thought of
IEEE arithmetic.

Ordered comparisons involving NaNs with new operators might be true or false
but never raise an exception.  Having control over exceptions is important
if you want to efficiently code library functions without raising gratuitous
exceptions.  Having language operators for a complete orthogonal set
of conditionals is preferable from the point of view of efficiency
to a set of external function calls.

As a practical matter I have my doubts that getting compiler implementers
to accept these extensions in NCEG is a good use of intellectual energy,
despite that the cost is pretty small compared to other things.

RETROSPECTIVE DIAGNOSTICS

The standard treatment of conventional comparison operators,
like all of IEEE 754, envisions retrospective diagnostics at the end of
execution to warn of possible problems overlooked.  I don't know yet how
to specify retrospective diagnostics in a general C environment.  In the
specific case of a native Unix environment, I've implemented retrospective
diagnostics for Sun Fortran by writing them to standard error. 

EXPRESSION EVALUATION

Our longest discussion was on expression evaluation issues.  Kahan's goal is
that you ought to be able to declare the expression evaluation paradigm that
you want if it matters.  The paradigms would be chosen from a short list
that might include some of

	Traditional Fortran (no gratuitous promotions)
	Traditional C (floats promoted to double)
	Widest available (all promoted to widest hardware precision)
	Widest needed (widest type in expression, described by Corbett)
	Natural (to a particular hardware)

Mr. Natural here is intended to encompass IBM RIOS multiply-add.  Note that
"Other" is specifically excluded to prevent further mutants.

As I have indicated earlier, I would be happier with two styles, "Conventional"
and "Natural".  "Conventional" would be agreed on, once and for all,
by NCEG - it could be
Traditional Fortran, Traditional C, or Widest Needed, as far as I'm 
concerned - they all share the property that rational expressions involving 
floats and doubles would produce identical results on all NCEG IEEE systems.  
Couple that with correctly-rounded base conversion and some elementary 
transcendental functions and program portability begins to mean something.

"Conventional" and "Natural" are really my previous "Standard" and
"Other" by less revealing names.   Which one is the default is not so 
important as being able to easily select either on any NCEG IEEE system.

If "Conventional" were default then the default
performance of existing Macintoshes would be rather adversely affected.
That's because 68882 extended rounding precision is rather costly to set
and once in effect slows things down measurably.  I can't get too worried
about that since anybody selecting a 68030 Macintosh for scientific
calculation did so for other reasons than floating-point performance.
So far the cost of a "Conventional" expression evaluation scheme on a
68040 system is not public knowledge.