Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

math: consider adding IEEE TiesToEven rounding to math package #21748

Closed
mpx opened this issue Sep 3, 2017 · 11 comments
Closed

math: consider adding IEEE TiesToEven rounding to math package #21748

mpx opened this issue Sep 3, 2017 · 11 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@mpx
Copy link
Contributor

mpx commented Sep 3, 2017

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
Copy link
Contributor Author

mpx commented Sep 3, 2017

CC @griesemer

@jimmyfrasche
Copy link
Member

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
Copy link
Contributor Author

mpx commented Sep 3, 2017

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
Copy link

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

@mpx
Copy link
Contributor Author

mpx commented Sep 3, 2017

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.

@mdempsky mdempsky changed the title Consider adding IEEE TiesToEven rounding to math package math: consider adding IEEE TiesToEven rounding to math package Sep 3, 2017
@ianlancetaylor ianlancetaylor added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Sep 9, 2017
@ianlancetaylor ianlancetaylor added this to the Go1.10 milestone Sep 9, 2017
@ianlancetaylor
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

mpx commented Sep 25, 2017

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

@mpx
Copy link
Contributor Author

mpx commented Oct 10, 2017

@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
Copy link
Contributor

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

@rsc
Copy link
Contributor

rsc commented Oct 23, 2017

OK but let's just do RoundToEven.

@rsc rsc added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 23, 2017
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Oct 23, 2017
@golang golang locked and limited conversation to collaborators Oct 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants