[MLton-user] bug report, strange floating point behavior
Matthew Fluet
fluet at tti-c.org
Sun Feb 18 14:08:13 PST 2007
> (*
> works
> *)
> fun go (x,y) 100000 = (print (Real.toString x ^ "\n");
> print (Real.toString (x+y) ^ "\n")
> )
> | go (x,y) i = go (x*y/3.0, x*9.0) (i+1)
>
> (*
> fails
> *)
> fun go2 (x,y) 100000 = print (Real.toString (x+y) ^ "\n")
> | go2 (x,y) i = go2 (x*y/3.0, x*9.0) (i+1)
>
> val _ = go (1.0/3.0, 3.0) 1
> val _ = go2 (1.0/3.0, 3.0) 1
>
> (*
> I expect the output of the previous code to be:
> 0.333333333333
> 3.33333333333
> 3.33333333333
>
> mlton without options produces
> 0.333333333333
> 3.33333333333
> 0
>
> with -ieee-fp true or -codegen bytecode, go2 produces the expected result
> tested with 20051202 and svn mlton as of yesterday
> *)
I've confirmed the behavior on x86-linux; what is interesting is that I
see the expected behavior with
-codegen native -ieee-fp
-codegen bytecode
and I see the unexpected behavior with
-codegen native
-codegen c
That leads me to believe that it could be explained by floating-point
rounding at extended 80bit precision, but I don't see exactly why.
More information about the MLton-user
mailing list