notes from a conference with Jim Thomas and W. Kahan

[uunet!Think.COM!frankel]

   Date: Fri, 10 Aug 90 16:08:37 PDT
   From: Bob Alverson <uunet!colossus.tera.com!bobauunet.UU.NET>

   * !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), 
   * 
   Why not make the !cc conditions without ? perform according to the
   standard's NOT(cc)?  For example:

   * < 	
   * 	true on less
   * 	false on equal or greater
   * 	false with invalid exception on unordered

   * <? or !>= 	
   * 	true on less or unordered
   * 	false on equal or greater

   For !>=, the standard would have true with invalid exception 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.

   The definition of !>= seems like a gratuitous deviation from the IEEE
   standard.  Why make it redundant with <? when that conveys the message?
   Hiding the ? by using the negation of the test seems like a step back
   rather than an improvement.

The <?, >?, <?=, and >?= operators are currently used by the C* language,
Thinking Machines' parallel C, as minimum, maximum, minimum assignment, and
maximum assignment operators, respectively.  These operators are quite
important to the language (they have parallel overloadings, perform
reductions, etc.).

If this group decides that unordered comparison operators are needed, I
strongly urge the group to agree on an alternate operator for unordered
comparisons so that it is compatible with prior art in this field and so that
Thinking Machines will be able to implement the new operators in a
compatible way.

Jamie Frankel