IEEE 754, the C99 standard, the Decimal IBM standard and Java all support/specify a 'remainder-near' operation. Apart from being standard, this has a number of useful applications:

1. Argument reduction in numerical algorithms: it's common to want to reduce to a range [-modulus/2, modulus/2] rather than [0, modulus).
2. Particular case of the above: reduction of angles to lie in the range [-pi, pi]
3. Rounding a float x to the nearest multiple of y. This is a much-asked StackOverflow question, and the standard answer of y * round(x / y) risks introducing floating-point error and so can give incorrect results in corner cases. With a remainder operation, it's trivial to do this correctly: x - remainder(x, y) gives the closest representable float to the closest integer multiple of y to x.

remainder(x, y) has some nice properties: it's *always* exactly representable (unlike x % y), it satisfies the symmetry remainder(-x, y) == -remainder(x, y), and it's periodic with period 2*y.

I have a patch, and will make a PR shortly.

See also Decimal.remainder_near and _PyLong_DivmodNear. Shouldn't the new function be named math.remainder_near?

In many cases the function that returns the nearest integer quotient is useful. See Fraction.__round__, datetime._divide_and_round, _pydecimal._div_nearest, etc.

Shouldn't the new function be named math.remainder_near?

Not clear. :-) I'd prefer to keep the name that's consistent with both C and IEEE 754. (We already have plenty of naming differences between Decimal and math; attempting to reconcile them is likely futile.)

FTR:

IEEE 754: remainder
C99: remainder
IBM Decimal spec: remainder-near
Java: IEEEremainder
.NET: IEEERemainder

In many cases the function that returns the nearest integer quotient is useful.

Agreed, but I'd like to keep the scope of this issue small for now: we're simply wrapping / implementing another C99 math.h function.

FTR, I don't have strong opinions on the name: I could be persuaded by any of remainder, remainder_near or ieee_remainder. I find ieee_remainder somewhat more informative than remainder_near.

I'd prefer to keep the name that's consistent with both C and IEEE 754.

+1

Also, the decimal module names are a poor guide. Its usability has been impaired by opaque naming (i.e. needing to use quantize() when you want to round to a fixed number of places).

New changeset a0ce375 by Mark Dickinson in branch 'master':
bpo-29962: add math.remainder (#950)
a0ce375