[MLton-user] IEEEReal rounding not working

Matthew Fluet fluet at tti-c.org
Thu Jul 26 11:26:52 PDT 2007


On Thu, 26 Jul 2007, Sean McLaughlin wrote:
> The attached program demonstrates a bug in the IEEEReal rounding mode
> setting:
>
> As you can see, the rounding modes are not having any effect.

Actually, the rounding modes are having a perfectly good effect.  The 
issue is that MLton interprets the primitive Real<N>.* operations as 
functional and, hence, amenable to common-subexpression-elimination. So, 
the subsequent "1.0 / 10.0" expressions are eliminated, and your program 
is executed as:

val mtenth_lo = (down();1.0 / 10.0)
val mtenth_hi = (up();mtenth_lo)
val mtenth_near = (near();mtenth_lo)
val mtenth_zero = (zero();mtenth_lo)

It is pretty easy to change the Real<N>.* operations to be non-functional 
(and, rather, that they depend on the current state), though I need to 
think about which ones precisely need to be switched.  It'll also have a 
performance impact, due to not eliminating (seemingly) redundant 
compuations.

On the x86, there is the additional screwy bit that you are computing at 
80-bits, and hence it is the rounding mode in effect when the value is 
spilled to memory that determines the 64-bit representation.  Now, you're 
saved by the fact that the IEEEReal.setRoundingMode function is 
implemented as a FFI call, so all real values are spilled to memory to 
abide by the C calling convention.  So, I don't think you'll end up with 
any artifacts due to that; but, it may very well be the case that a 
sequence of floating-point computations carried out at 80-bits under 
rounding mode m and then converted to 64-bits via rounding mode m could 
yield a different answer than performing the sequence of floating-point 
computations at 64-bits under rounding mode m.  But, I don't think 
MLton/SML will be any different than gcc/C in this regard.

BTW, would you expect the following output:

3FB9999999999999
3FB999999999999A
3FB999999999999A
3FB9999999999999

which is what I get by making the Real_div primitive depend on state, 
rather than functional.




More information about the MLton-user mailing list