Up and down
round_up() does what most people think of as rounding.
If the decimal portion to be cut off by rounding is 5 or greater, it
rounds up. Otherwise, it rounds down.
round_up(x = 1.24, digits = 1)
#> [1] 1.2
round_up(x = 1.25, digits = 1)
#> [1] 1.3
round_up(x = 1.25) # default for `digits` is 0
#> [1] 1
Rounding up from 5 is actually a special case of
round_up_from(), which can take any numeric threshold, not
just 5:
round_up_from(x = 4.28, digits = 1, threshold = 9)
#> [1] 4.2
round_up_from(x = 4.28, digits = 1, threshold = 1)
#> [1] 4.3
These two functions have their mirror images in
round_down() and round_down_from(). The
arguments are the same as in round_up():
round_down(x = 1.24, digits = 1)
#> [1] 1.2
round_down(x = 1.25, digits = 1)
#> [1] 1.2
round_down(x = 1.25) # default for `digits` is 0
#> [1] 1
round_up_from() rounds up when the part cut off by
rounding is at least \(t\) tenths of a
step, and round_down_from() rounds down when that part is
at most \(t\) tenths. With the same
threshold, the two switch direction at the same point:
round_down_from(x = 4.28, digits = 1, threshold = 9)
#> [1] 4.2
round_down_from(x = 4.28, digits = 1, threshold = 1)
#> [1] 4.3
They only differ for a value exactly on the threshold:
round_up_from(x = 4.25, digits = 1, threshold = 5)
#> [1] 4.3
round_down_from(x = 4.25, digits = 1, threshold = 5)
#> [1] 4.2
Rounding up implements this formula:
\[\frac{\lfloor x(10^d) +1 - \frac{t}{10}
+ \epsilon \rfloor}{10^d}\]
where \(x\) is the number to be
rounded, \(d\) is the number of decimal
places to which \(x\) should be
rounded, and \(t\) is the threshold for
rounding up (e.g., \(t = 5\) for
rounding up from 5). Note that \(\lfloor n
\rfloor\) floors a number \(n\),
and \(\lceil n \rceil\) ceils it.
Rounding down works accordingly:
\[\frac{\lceil x(10^d) - \frac{t}{10} -
\epsilon \rceil}{10^d}\]
The \(\epsilon\) in both formulas is
a fixed tolerance of about \(1.5 \times
10^{-9}\). It is there because shifting \(x\) by \(d\) decimal places is not exact: \(0.145 \times 100\) is stored as \(14.499999999999998\), a hair below the tie
it is meant to be, and rounding that shifted value directly would move
\(0.145\) a whole step in the wrong
direction. The same tolerance is applied by every other
round_*() function, and unround() reports
bounds that assume it, so a number and its reconstructed range always
agree. See the Floating-point tolerance section of
round_up().
Ties, named directly
round_up() and round_down() say which way a
tie goes on the number line, and symmetric then
decides what that means below zero. Since that translation is easy to
get backwards, the same procedures are also available under names that
state them outright:
round_ties_up(-2.5) # Stata
#> [1] -2
round_ties_down(-2.5)
#> [1] -3
round_ties_away(-2.5) # Excel, SPSS, SAS, Matlab
#> [1] -3
round_ties_zero(-2.5)
#> [1] -2
round_ties_even(-2.5) # `base::round()`
#> [1] -2
round_ties_up() is round_up() with
symmetric = FALSE, and round_ties_away() is
round_up() with symmetric = TRUE. Nothing is
deprecated by them; use whichever spelling reads better. The
rounding strings "ties_up",
"ties_down", "ties_away",
"ties_zero", and "ties_even" name the same
procedures inside reround() and unround().
Each of them already determines the direction of a tie for negative
numbers as well, so combining them with symmetric = TRUE is
an error.
To even (base R)
Like Python’s round()
function, R’s base::round() doesn’t round up or down, or
use any other procedure based solely on the truncated part of the
number. Instead, round() strives to round to the next even
number. This is also called “banker’s rounding”, and it follows a
technical standard, IEEE
754.
Realizing that round() works in a highly unintuitive way
sometimes leads to consternation. Why can’t we just round like we
learned in school, that is, up from 5? The reason seems to be bias.
Because 5 is right in between two whole numbers, any procedure that
rounds 5 in some predetermined direction introduces a bias toward that
direction. Rounding up from 5 is therefore biased upward, and rounding
down from 5 is biased downward.
As shown in the Rounding bias section below, this is
unlikely to be a major issue when rounding raw numbers that originally
have many decimal places. It might be more serious, however, if the
initial number of decimal places is low (for whatever reason) and the
need for precision is high.
At least in theory, “rounding to even” is not biased in either
direction, and it preserves the mean of the original distribution. That
is how round() aims to operate. Here is a case in which it
works out, whereas the bias of rounding up or down is fully
apparent:
vec1 <- seq(from = 0.5, to = 9.5)
up1 <- round_up(vec1)
down1 <- round_down(vec1)
even1 <- round(vec1)
vec1
#> [1] 0.5 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
up1
#> [1] 1 2 3 4 5 6 7 8 9 10
down1
#> [1] 0 1 2 3 4 5 6 7 8 9
even1
#> [1] 0 2 2 4 4 6 6 8 8 10
# Original mean
mean(vec1)
#> [1] 5
# Means when rounding up or down: bias!
mean(up1)
#> [1] 5.5
mean(down1)
#> [1] 4.5
# Mean when rounding to even: no bias
mean(even1)
#> [1] 5
However, unbiased in theory does not mean unbiased in every sample.
Rounding to even only preserves the mean if the even neighbors fall
equally often above and below the ties. Here, all values are exact ties,
but four of the seven have their even neighbor below:
vec2 <- seq(from = 4.5, to = 10.5)
up2 <- round_up(vec2)
down2 <- round_down(vec2)
even2 <- round(vec2)
vec2
#> [1] 4.5 5.5 6.5 7.5 8.5 9.5 10.5
up2
#> [1] 5 6 7 8 9 10 11
down2
#> [1] 4 5 6 7 8 9 10
even2 # Every tie goes to even...
#> [1] 4 6 6 8 8 10 10
mean(vec2)
#> [1] 7.5
mean(up2)
#> [1] 8
mean(down2)
#> [1] 7
mean(even2) # ... but the mean is biased downward!
#> [1] 7.428571
Floating-point arithmetic adds a second complication. Most decimal
fractions cannot be represented exactly in binary, so numbers that look
like ties usually are not. round() then rounds them to the
nearer neighbor, even or not. Below, 1.15 goes to
1.1 and 1.85 to 1.9:
vec3 <- c(
1.05,
1.15,
1.25,
1.35,
1.45,
1.55,
1.65,
1.75,
1.85,
1.95
)
# Still, the mean is preserved here:
round(vec3, 1)
#> [1] 1.0 1.1 1.2 1.4 1.4 1.6 1.6 1.8 1.9 2.0
mean(vec3)
#> [1] 1.5
mean(round(vec3, 1))
#> [1] 1.5
Sometimes round() behaves just as it should, but at
other times, results can be hard to explain. Martin Mächler, who wrote
the present version of round(), describes the issue about
as follows:
The reason for the above behavior is that most decimal fractions
can’t, in fact, be represented as double precision numbers. Even
seemingly “clean” numbers with only a few decimal places come with a
long invisible mantissa, and are therefore closer to one side or the
other. (To see this clearly, try entering a few decimal numbers on Float Exposed.)
We usually think that rounding rules are all about breaking a tie
that occurs at 5. Most floating-point numbers, however, are just
somewhat less than or greater than 5. There is no tie! Consequently,
Mächler says, rounding functions need to “measure, not guess
which of the two possible decimals is closer to x” — and
therefore, which way to round.
This seems better than following mathematical intuitions that may not
always correspond to the way computers actually deal with numbers. R has
used the present solution since version 4.0.0.
base::round() can seem like a black box, but it seems
unbiased in the long run. I recommend using round() for
original work.
For reconstruction, two claims about round() are easy to
run together. base::round() is the right way to reconstruct
software that rounds binary doubles to even, such as R itself, Python,
and NumPy. This is what rounding = "even" does. What is
unsuitable is the reverse: Predicting round()’s output from
the decimal you see written down, since most decimals are not exactly
representable and so are not really ties at all. Reconstructing the many
programs that do round from the decimal 5 is the job of roundwork’s
other round_*() functions. See
vignette("rounding-options"), which lists which program
falls on which side.
IEEE 754 rounding standard
If you need to follow the IEEE 754 rounding standard, see
round_ties_to_even() for wrapper functions that implement
all five IEEE rounding procedures (or “rounding-direction attributes”).
IEEE 754 defines standards for floating-point operations, which includes
rounding (IEEE 2019, pp. 27f.; the Wikipedia
page is more accessible).
Each of them is a wrapper around a function that roundwork already
had under a name of its own:
round_ties_to_even() |
base::round() |
round_ties_to_away() |
round_ties_away(), i.e. round_up() with
symmetric = TRUE |
round_toward_positive() |
round_ceiling() |
round_toward_negative() |
round_floor() |
round_toward_zero() |
round_trunc() |
The duplication is deliberate. roundwork’s own names were chosen
without the standard in mind, and renaming them would break every
downstream caller; but a function that says roundTowardPositive
on the tin is easier to reach for when a paper or a manual states its
rounding in the standard’s vocabulary. Note that the standard has no
name for the other three tie-breaking procedures, for rounding away from
zero (round_anti_trunc()), or for the custom thresholds of
round_up_from().
