Fwd: [MLton-user] IEEEReal rounding not working

[Sean McLaughlin]

Hello,

  Thanks again for the fix.  I found another quirk though:

Seems like fromString is going the wrong way for negative numbers.

  structure I = IEEEReal
  structure R = Real
  structure V = Word8Vector
  structure P = PackRealBig

  fun down() = I.setRoundingMode I.TO_NEGINF
  fun up() = I.setRoundingMode I.TO_POSINF

  fun word8vectorToString v = V.foldr (fn(w,s) => Word8.toString w ^ s) "" v

  val _ = down()
  val x = ~1.0/10.0
  val _ = up()
  val y = ~1.0/10.0
  val _ = if R.<=(x,y) then print "YES\n" else print "NO\n"
  val _ = print(word8vectorToString (P.toBytes x) ^ "\n")
  val _ = print(word8vectorToString (P.toBytes y) ^ "\n")

  val s = "~0.1"
  val _ = down()
  val x = Option.valOf (Real.fromString s)
  val _ = up()
  val y = Option.valOf (Real.fromString s)
  val _ = if R.<=(x,y) then print "YES\n" else print "NO\n"
  val _ = print(word8vectorToString (P.toBytes x) ^ "\n")
  val _ = print(word8vectorToString (P.toBytes y) ^ "\n")

~/save/versioned/projects/kepler/sml
$ YES
BFB999999999999A
BFB9999999999999
NO
BFB9999999999999
BFB999999999999A

Is this something you'd be interested in fixing, though the Definition
doesn't
specify rounding behavior for fromString, or shall I just avoid fromString
as well as I can?

Thanks!

Sean



On 7/29/07, Matthew Fluet <fluet at tti-c.org> wrote:
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20070806/be58d314/attachment.htm