Fwd: [MLton-user] IEEEReal rounding not working

[Matthew Fluet]

On Fri, 27 Jul 2007, Sean McLaughlin wrote:
>> From my experience with C compilers, I would never trust that writing
> a [real] constant would round correctly.  It seems every compiler I've seen
> the equivalent of atof, which rounds according to the rounding mode
> at compile time.  A major concern then, is to have a safe way of getting
> hold of a 64 bit floating point constant where you, in principle, know all
> the bit values, say from the Mathematica RealDigits function.
> I've written a function like this that plays with PackRealBig.

I think that bouncing through PackReal is the portably way of getting 
exactly the bits you want.

> A very similar question is, what should this do?
>
> (up();Math.pi)
>
> It would be very strange to have a library constant like Math.pi have
> dynamic content...

Yes that would be strange, and somewhat inconsistent with the semantics of 
the language.  Math.pi is an immutable value -- one that never changes.
The binding of Math.pi to a value occurs when the Math structure is 
evaluated, so occurs according to the initial rounding mode.
One might have:
   Math.roundPi : unit -> real
that gives you pi according the the current rounding mode, but the 
explicit thunk makes it clear that it is somehow context dependent.

> Real.compare(Math.pi, (up();Math.pi)) ~~> false
>
> As a total amateur, I would say that some function like
>
> val Real.roundFromString : string -> real option
>
> that guarantees to respect the rounding mode is all that would be necessary
> to do perfectly satisfactory mathematics with interval arithmetic.
> (I don't know if the standard specifies this for  Real.fromStringfunction...)

I think the Real.{to,from}Decimal are the closest, though the Basis 
Library explicitly states that the conversions occur under TO_NEAREST.
I believe that the Real.fromString function works according to the current 
rounding mode.