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.