benchmarking Poly/ML & floating point

Stephen Weeks sweeks@intertrust.com
Mon, 11 Sep 2000 14:58:47 -0700 (PDT)


> So, I think it comes down to the fact that 
> #define Real_qequal(x,y) (!((x) != (y)))
> isn't the right semantics.

Great.  We all agree.

> But the spec states:
> ?= (x, y) 
>     returns true if either argument is a NaN or if the arguments are
> bitwise equal, ignoring signs on zeros. It is equivalent to the IEEE ?=
> operator. 
> 
> The short end of the story is that I found the assembly for isgreaterless
> in /usr/include/bits/mathinline.h (although I can't figure out how to get
> gcc to include it; just #define __USE_ISOC9X causes parse errors in
> mathinline.h, so obviously no one is that concerned about following the
> spec that closely), and it seems to jive with what the intel spec has on
> the floating-point status word, so I'm inclined to go with it.

I earlier said that the right thing is to do is

val op ?= = fn (x, y) => isNan x orelse isNan y orelse x == y

But after your mail, I gather that you can do qequal with one test, and if so,
then the right thing to do is to leave qequal as a primitive, and to make
mlton-lib.h do the right thing for Real_qequal.