benchmarking Poly/ML & floating point

[Stephen Weeks]

> No, I haven't seen merge.  Is it in the latest tar.gz that you posted?

No.  But it is available at http://www.sourcelight.com/MLton/benchmarks/

> In other news, I have a mostly complete floating point backend set up.  It
> natively handles all of the prim's except: cosh, sinh, tanh, exp, pow,
> tan, which are done as ffi calls.  It also does ffi calls for copysign,
> frexp, and modf, but does not have any inline assembly for those
> operations.  (On the other hand, for the first group of prims, gcc does
> have inline assembly, but I haven't been able to completely grok it all;
> particularly something like pow which has lots of branching and special
> cases to consider. 

My guess would be that the right thing to do is to move these cases into SML
basis library code and make the primitive as simple as possible.  I don't mind
if some of the tests are duplicated in the SML code and the C backend.

> I'm not sure that the semantics of Real_nequal and Real_qequal as given in
> mlton-lib.h are correct. For one thing, gcc produces the same assembly
> sequence for both functions. 

How can this be?  Looking at mlton-lib.h I see that Real_qequal is the negation
of Real_nequal -- this may or may not be wrong, but I don't see how it could
lead to the same code.

> Also, looking at the basis spec,
>  !=  is equivalent to  not o ==   vs.  #define Real_nequal(x,y) ((x) != (y))

This seems simple enough.  I'll change the basis library implementation and
remove Real_nequal as a primitive alltogether.  Although we should also send a
message to Reppy indicating that the top part of the Real spec is messed up,
since it says that SML != is the same as C !=.  Wait a second, I just composed
the following simple C program to test what's going on.

#include <stdio.h>

int main() {
	double x = 1.0/0.0 + -1.0/0.0;
	fprintf(stderr, "%f\n", x);
	fprintf(stderr, "%d\n", x == 1.0);
	fprintf(stderr, "%d\n", x != 1.0);
	fprintf(stderr, "%d\n", !(x == 1.0));
}

It's output is

nan
0
1
1

> Won't IEEE floating point return false on any comparison when one argument
> is NaN?

The above C program (in particular, the second comparison) seems to contradict
this.  Or is the problem that C isn't IEEE?  I'm now completely confused.