Hello,<br><br> Thanks again for the fix. I found another quirk though:<br><br>Seems like fromString is going the wrong way for negative numbers.<br><br> structure I = IEEEReal<br> structure R = Real <br> structure V = Word8Vector
<br> structure P = PackRealBig<br><br> fun down() = I.setRoundingMode I.TO_NEGINF<br> fun up() = I.setRoundingMode I.TO_POSINF<br><br> fun word8vectorToString v = V.foldr (fn(w,s) => Word8.toString w ^ s) "" v
<br><br> val _ = down()<br> val x = ~1.0/10.0<br> val _ = up()<br> val y = ~1.0/10.0<br> val _ = if R.<=(x,y) then print "YES\n" else print "NO\n"<br> val _ = print(word8vectorToString (P.toBytes
x) ^ "\n")<br> val _ = print(word8vectorToString (P.toBytes y) ^ "\n")<br><br> val s = "~0.1"<br> val _ = down()<br> val x = Option.valOf (Real.fromString s)<br> val _ = up()<br> val y =
Option.valOf (Real.fromString s)<br> val _ = if R.<=(x,y) then print "YES\n" else print "NO\n"<br> val _ = print(word8vectorToString (P.toBytes x) ^ "\n")<br> val _ = print(word8vectorToString (
P.toBytes y) ^ "\n")<br><br>~/save/versioned/projects/kepler/sml<br>$ YES<br>BFB999999999999A<br>BFB9999999999999<br>NO<br>BFB9999999999999<br>BFB999999999999A<br><br>Is this something you'd be interested in fixing, though the Definition doesn't
<br>specify rounding behavior for fromString, or shall I just avoid fromString<br>as well as I can?<br><br>Thanks!<br><br>Sean<br><br><br><br><div><span class="gmail_quote">On 7/29/07, <b class="gmail_sendername">Matthew Fluet
</b> <<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Fri, 27 Jul 2007, Sean McLaughlin wrote:
<br>>> From my experience with C compilers, I would never trust that writing<br>> a [real] constant would round correctly. It seems every compiler I've seen<br>> the equivalent of atof, which rounds according to the rounding mode
<br>> at compile time. A major concern then, is to have a safe way of getting<br>> hold of a 64 bit floating point constant where you, in principle, know all<br>> the bit values, say from the Mathematica RealDigits function.
<br>> I've written a function like this that plays with PackRealBig.<br><br>I think that bouncing through PackReal is the portably way of getting<br>exactly the bits you want.<br><br>> A very similar question is, what should this do?
<br>><br>> (up();Math.pi)<br>><br>> It would be very strange to have a library constant like Math.pi have<br>> dynamic content...<br><br>Yes that would be strange, and somewhat inconsistent with the semantics of
<br>the language. Math.pi is an immutable value -- one that never changes.<br>The binding of Math.pi to a value occurs when the Math structure is<br>evaluated, so occurs according to the initial rounding mode.<br>One might have:
<br> Math.roundPi : unit -> real<br>that gives you pi according the the current rounding mode, but the<br>explicit thunk makes it clear that it is somehow context dependent.<br><br>> Real.compare(Math.pi, (up();Math.pi)) ~~> false
<br>><br>> As a total amateur, I would say that some function like<br>><br>> val Real.roundFromString : string -> real option<br>><br>> that guarantees to respect the rounding mode is all that would be necessary
<br>> to do perfectly satisfactory mathematics with interval arithmetic.<br>> (I don't know if the standard specifies this for Real.fromStringfunction...)<br><br>I think the Real.{to,from}Decimal are the closest, though the Basis
<br>Library explicitly states that the conversions occur under TO_NEAREST.<br>I believe that the Real.fromString function works according to the current<br>rounding mode.<br><br></blockquote></div><br>