NaNs vs Comparisons vs <>

[D. Hugh Redelmeier]

I am a purist and am not a number cruncher, two things that should
disqualify my opinions from consideration, but ...

- I don't like <> for not equal because it implies that the things
  being compared are from a fully ordered set.  The justification
  for <> meaning != comes from trichotomy.  If this seems too strong,
  replace "it implies" with "I infer"; this I can assure you is true.

  Complex types should not be fully ordered.  Pointer types are not
  fully ordered (pointers are not ordered if they point into
  different objects).  String equality seems to be a simpler problem
  than string ordering.

  Even for integral types, this may have the wrong "feel" to it.
  For example, if the integers actually represent values mod some
  integer.  Consider the implementation of a circular buffer with
  head and tail indices: testing for equality is necessary; testing
  for order is meaningless.

- I don't like x==x ever being false (except as a possible outcome
  from undefined behaviour).  I don't like non-signaling NaNs being
  silently accepted in comparisons that don't shout "I am an
  operator that deals with NaNs" at the writer and the reader.  To
  me, the traditional comparisons don't shout this message.  They
  certainly didn't mean that for programs that were not written for
  IEEE fp.

  I grudgingly accept non-signaling NaNs as legitimate operands for
  most operators.  What is different about comparisons?  Comparisons
  create discontinuity.  Discontinuity is very tricky.  It should
  *never* be created where the programmer or the reader did not
  intend or expect it.  In the context of a boolean expression, I
  assert that it is not manifest which result would produce the
  "default" behaviour; there may not even be a default.

  I think that the traditional comparison operators should abort
  when given a NaN operand (without burdening the implementation
  with the requirement that the code might resume).  Of course, in
  the tradition of C, the result of a comparison with a NaN operand
  would be prescribed as undefined (better: implementation defined);
  this would allow implementations to do what they wanted with such a
  comparison.  I want an implementation to be *allowed* to abort.

  I think that a single predicate to test for NaN-ness should be
  enough to write all the code that is desired.  I think that the
  result will be clearer than the alternatives.  Simple peephole
  optimization could usually synthesize code equivalent to that
  produced for the fancy new operators suggested.

- Complex numbers are not naturally ordered.  Any ordering imposed
  on them suffers from either discontinuity or incompleteness.  If a
  programmer wishes to design an ordering, let him.  We ought not to
  build an arbitrary and defective one into C.

Hugh Redelmeier
{utcsri, yunexus, uunet!attcan, utzoo, scocan}!redvax!hugh
When all else fails: hughacsri.toronto.edu
+1 416 482-8253