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.

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: [...]

On Sat, Oct 28, 2017 at 10:17 PM, Alex Shinn <xxxxxx@gmail.com> wrote:

On Sat, Oct 28, 2017 at 5:25 AM, Shiro Kawai <xxxxxx@gmail.com> 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.

-- 

Alex