[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