The chapter "Permission to Guess" explains how to "round" unums. The "guess" function replaces an inexact unum with an exact one, either the one closest to the midpoint if there is at least one more bit of fraction precision available, or one of the endpoints if the ULP size is already as small as it can be in a given environment. The latter case is rounding, and can be round-toward-zero, round-toward-toward-infinity, round-toward-negative-infinity, round-to-nearest-even, round-to-nearest-odd, or whatever policy you want to establish. That policy can be set with an environment flag, and it probably should default to round-to-nearest-even to best imitate typical use of IEEE 754 floats.
On Thursday, July 30, 2015 at 6:47:20 AM UTC-7, Tom Breloff wrote: > > Simon: if I understand what you're suggesting, you'd like to add a > "rounding direction" flag whenever the ubit is set that would indicate > which direction you *would* round if you wanted to? I like this idea, as > it allows you to throw away the implicit open interval in favor of a > rounded exact value (if that's what you want). You potentially get the > best of both worlds, but with the speed/memory penalty of setting that > extra bit? I can't really comment yet on how much processing this would > add... > > On Thu, Jul 30, 2015 at 9:18 AM, Simon Byrne <[email protected] > <javascript:>> wrote: > >> On Wednesday, 29 July 2015 22:07:45 UTC+1, Steven G. Johnson wrote: >>> >>> And I don't see a clear practical use-case for an inexact bit per value, >>> as opposed to a single inexact flag for a whole set of computations (as in >>> IEEE). >>> >> >> Probably not quite what others had in mind, but an instruction-specific >> inexact flag (and rounding mode) would make it possible to implement >> round-to-odd fairly neatly (e.g., see here >> <http://www.exploringbinary.com/gcc-avoids-double-rounding-errors-with-round-to-odd/>), >> >> which would in turn allow implementing all the "formatOf" operations in the >> IEE754-2008 standard. >> > >
