math: consider adding IEEE TiesToEven rounding to math package

[mpx]

IEEE 754-2008 specifies 5 rounding-direction attributes with 4 implemented by the math package:

• roundTiesToEven: RoundTiesToEven (proposed) (was Rint)
• roundTiesToAway: Round
• roundTowardPositive: Ceil
• roundTowardNegative: Floor
• roundTowardZero: Trunc

No other rounding-attributes are specified by IEEE 754. There have been various proposals in the past requesting highly configurable esoteric rounding modes beyond IEEE. I don't believe they should be considered for the math package.

I'd suggest using the following signature: func RoundTiesToEven(float64) float64

Most people generally prefer TiesToAway for common usage (hence #20100). However TiesToEven has statistical properties that are preferable for some applications. Implementations of IEEE 754 are required to provide TiesToEven.

For comparison, other languages provide support for TiesToEven:

• C99: rint
• Java: Math.rint
• Python v3 (not v2): round

Pro:

• Statistically useful for some applications.
• Easy to implement incorrectly with many subtle edge-cases. A reliable stdlib implementation prevents bugs.
• Required for IEEE 754. It's the only mode not supported by the math package and would complete IEEE rounding support.
• math package is the most appropriate location for TiesToEven support since all the other modes are in math.

Con:

• +1 function to math package API.

[mpx]

CC @griesemer

[jimmyfrasche]

Rint is a bad name unless you know what it means and it being shorter than the more common Round serves little purpose. Something more like RoundToEven says what it does and it being longer than Round implies that Round is probably what you want unless you have a special need.

[mpx]

I ended up with Rint since it is commonly used by other languages, and the functions in the math package are typically named fairly briefly. RoundToEven, RoundTiesToEven, RoundTiesEven,.. work for me as well - whatever works best for the keepers of the API (if they decide to support this mode at all).

[gopherbot]

Change https://golang.org/cl/61211 mentions this issue: math: Add Rint function (round ties to even)

[mpx]

I already had a tested implementation, so I've included it for review. The larger question is still whether or not the project wants to support the last IEEE mode.

[ianlancetaylor]

C99 defines a function nearbyint that is the same as the C99 rint function except that nearbyint never raises the FE_INEXACT exception. (The C99 rint and nearbyint functions do not in fact implement round-to-even. They both round using the current rounding direction, as set by fesetround. The default rounding mode is round-to-nearest which means the same thing as round-to-even.)

The name rint is not used by IEEE-754. Java calls the function Math.rint. Fortran calls it NINT. C# calls it Math.Round.

Since we tend to follow C, this is all by way of saying that I think NearByInt would be as good a name as Rint for this function in the math package.

[griesemer]

Now that we have Round perhaps we should bite the bullet and just complete the set. I'm not a fan of Rint - it's close to saying nothing. NearByInt could as well just mean Round. RoundToEven or RoundTiesToEven or RoundToNearestEven seem much clearer.

[mpx]

I'd lean towards RoundTiesToEven for a more descriptive name. RoundToEven/RoundToNearestEven might seem to imply they only return even numbers.

[mpx]

@griesemer, is there a decision on adding RoundTiesToEven? If it's ok, the code is more-or-less ready (pending review) for 1.10.

[griesemer]

I'm in favor, for completeness sake, but there was no formal decision (by the proposal committee) yet.

[rsc]

OK but let's just do RoundToEven.