[Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers

[Nick Bowler]

On 13:30 Thu 22 Apr     , Casey McCann wrote:
> On Thu, Apr 22, 2010 at 11:34 AM, Barak A. Pearlmutter <barak at cs.nuim.ie> wrote:
> > Comparison of exceptional IEEE floating point numbers, like Nan, seems
> > to have some bugs in ghci (version 6.12.1).
> 
> Arguably, the "bug" in question is the mere existence of Eq and Ord
> instances for IEEE floats. They don't, can't, and never will work
> correctly. A similar topic was discussed here not too long ago; IEEE
> floating point so-called "numbers" lack reflexive equality and
> associativity of addition and multiplication, among other properties
> one might take for granted in anything calling itself a number.

Lack of reflexivity in the Eq instance is, in my opinion, an extremely
minor detail.  I can't think of any library functions off-hand that both

 (a) Might reasonably be used in the context of floating point
     computation.
 (b) In the presence of NaNs, depend on reflexivity of (==) for correct
     behaviour.

Now, lack of totality of the Ord instance is actually a severe problem,
because I can immediately think of a function that is both useful and
depends on this: sort.  If we define "list is sorted" as "every element
except the last is less than or equal to its successor", sort does not
necessarily produce a sorted list!  In fact, as I posted elsewhere, the
result of sort in this case depends on the particular algorithm used.

For all intents and purposes, a class for partial orders would be
totally fine for floating point.  Sure, it's not reflexive in the
presence of NaNs.  Sure, it's not antisymmetric in the presence of
negative zeros.  On the other hand, it does satisfy a restricted form
of reflexivity and antisymmetry:

  * x == y implies x <= y
  * x <= y and y <= x implies x == y

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)