Fwd: [MLton-user] IEEEReal rounding not working

[Sean McLaughlin]

---------- Forwarded message ----------
From: Sean McLaughlin <seanmcl at gmail.com>
Date: Jul 27, 2007 11:58 AM
Subject: Re: [MLton-user] IEEEReal rounding not working
To: Matthew Fluet <fluet at tti-c.org>

Hi,


> The other aspect that I was wondering about was floating-point constants.
> That is, what should the following program do:
>
> val mtenth_lo = (down(); 0.1)
> val mtenth_hi = (up(); 0.1)
> val mtenth_near = (near(); 0.1)
> val mtenth_zero = (zero(); 0.1)
>
> val _ = print(word8vectorToString ( P.toBytes mtenth_lo) ^ "\n")
> val _ = print(word8vectorToString (P.toBytes mtenth_hi) ^ "\n")
> val _ = print(word8vectorToString (P.toBytes mtenth_near) ^ "\n")
> val _ = print(word8vectorToString ( P.toBytes mtenth_zero) ^ "\n")




>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.
Of course, it would be much nicer, and less error prone, to be able to write
the above code.
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...
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...)
This would of course punt on trying to pin down the state of the Real and
IEEEReal
structures wrt The Definition, but I'm not enough of an expert to offer
advice on that
issue.

Best,

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20070727/16e104fa/attachment.htm