NaN Nonsense

Gary Leavens has a paper in the current issue of the Journal of Object Technology in which he describes the problems caused by NaN (Not-a-Number) values in the specification of software involving IEEE 754 floating point computations.  It never ceases to dismay me how ready some people are to use single (defined) values to represent undefined values.  They then get themselves tied up in knots over such questions as whether one NaN should be equal to another NaN, or whether NaN should be a number or not.  If you think I am just joking about the latter then read the following quotation from Leaven's paper:

The tricotomy law says that either x < y, x = y, or x > y; but if either x or y is NaN, then all three of these expressions may be false. Violation of tricotomy tells us that, with NaN, floating-point numbers are no longer totally ordered.  Of course, this makes sense if you consider NaN to be “not a number” as only the numbers are totally ordered.  The trouble is that type systems usually consider NaN to be a number.

Type systems consider 'Not-a-Number' to be a number!  And people don't even seem to wonder why they run into difficulties with this approach.  This is precisely the sort of silliness that I was complaining about in my Undefined Values should remain Undefined.

I agree with Leavens that the best solution to the NaN problems is to dispense with them altogether and to throw an exception on the failure of the precondition for a floating point operation.  This would be the 'Design by Contract' approach.