Sorry for the late reply.

On Mon, Oct 30, 2017 at 11:01 AM, Shiro Kawai <> wrote:
That's right, and there I still haven't got a clear opinion.  Using round-half-to-even would be consistent with round, and probably so in other parts of the implementation (e.g. the built-in string->number and number->string might be using round-half-to-even whenever tie-breaking is required).
Initially I implemented Gauche's notational rounding with round-half-to-even.  But then I thought it might not be what users expect---when a user thinks 5.015 rounded down to 5.01 is a bug, she is assuming round-half-to-infinity.  I assume nobody would pick on statistical bias after notationally rounded numbers so I changed Gauche to use round-half-to-infinity.   It does appear to be an arbitrary choice.

Maybe this complexity is the reason that many programming language / implementations are vague on this.  It's not worth to define precisely, they think.

Here are some options I can think of right now:

Option 1:
We take the same path with others, just saying numbers falling near the midpoint may be rounded up or down, it's implementation dependent.

Option 2:
Potentially over-engineering specification:
* Must have a way to guarantee notational rounding (it's ok to only provide notational rounding; the impl may provide more efficient, native effective rounding as an option)
* Have an option to specify round-half-to-even or round-half-to-infinity
* Say exact number must be treated exact while generating digits, e.g. converting it to flonum first isn't an option.
If we go down this strict path, we might end up providing full Burger&Dybvig algorithm in the reference implementation, to guarantee the consistent digit generation across implementations.

Option 3:
Make the option 2 an "option", and add some mechanism to query what the implementation provides.
It reduces the burden from the implementors.  Easier for the implementation that already has customizable flonum formatter to adopt srfi-159.
An application that prefer notational rounding at least can warn users if it's not the case.

Option 4:
Make the number formatter pluggable.  Can be done with the current spec by just replacing numeric, but we can also define lower-level callback that only generates digits (comma etc. are handled in srfi-159).  The default is implementation-dependent (with the loose definition like option 1).  Separate srfi would provide various digit generators.  Can be combined with option 3.

I think for option 4 we can rely on replacing numeric - the whole system is intended to be pluggable.
Option 2 also sounds like a large burden, so the choice should be between options 1 and 3.
Since there are arguments for both notational and effective rounding, we wouldn't want to make
either the default, and would need to allow a way to achieve both.  We could consider new
parameters to control this:

  - rounding: any of 'native, 'effective, 'notational
  - rounding-direction: any of 'native, 'even, 'infinity

Plus utility procedures `show-get-supported-roundings' and `show-get-supported-rounding-directions'
to return a list of the supported values for these parameters (extensions of course allowed).

I'm just worried this is over-engineering.  Would anyone else want this?

Note the spec as written already requires arbitrary precision for exact numbers:

Implementations should allow arbitrary precision for exact rational numbers,
for example, using string-segment from SRFI 152, the following code
returns the first 100 Fibonacci numbers: [...]

We could explicitly note that conversion to inexact is forbidden, but that
rules out implementations which convert to arbitrary precision inexact
which covers the current precision.


On Sat, Oct 28, 2017 at 10:17 PM, Alex Shinn <> wrote:
On Sat, Oct 28, 2017 at 5:25 AM, Shiro Kawai <> wrote:
If you mean round-half-to-even, it is orthogonal to effective vs notational rounding.  1.15 in binary floating point number is not on a midpoint of 1.1 and 1.2, so no need of tie-breaking.
If you mean always round to even, the result would be consistent across implementations,  We could list that (though it's different behavior than Scheme's "round"; the difference is apparent when precision is 0).

Right, it's orthogonal.  For implementations using notational rounding,
it needs to be addressed though.  We should also say something about
how the exact number 115/100 is supposed to round.