Why SAS and R Round Differently (and How to Make Them Agree)

SAS rounds half away from zero; R’s round() rounds half to even and works on binary floating point. Here is exactly where the differences appear in clinical tables, how to reproduce SAS rounding in R, and which rule to write into your tolerance document.

• SAS ROUND(x, 0.1) rounds half away from zero. R’s round(x, 1) follows IEC 60559 and rounds half to even, so round(2.5) is 2 and round(0.125, 2) depends on the binary representation.
• In a typical TLF package the mismatch shows up in a handful of cells per table: percentages that end in exactly 5 at the next digit, means of integer data, and derived values such as BMI.
• A six-line round_sas() helper reproduces SAS behaviour in R. Put it in your migration package, test it, and reference it in the numerical tolerance rules.
• The right policy is usually “match SAS during parallel runs, then adopt one convention site-wide”, not “argue each cell”.

If you have ever compared an R table to its SAS original and found a 12.5 % that became 12.4 %, you have met the single most common source of SAS-to-R “discrepancies”. It is not a bug on either side. The two systems implement different, equally defensible rounding rules, and they sit on top of binary floating-point arithmetic that makes some decimals impossible to represent exactly.

The two rules

SAS ROUND() rounds half away from zero: 2.5 becomes 3, −2.5 becomes −3, 0.125 to two decimals becomes 0.13. Internally SAS also applies a “fuzz” so that values that are almost a half, due to floating-point noise, are treated as a half.

R round() documents that it follows the IEC 60559 standard: “round half to even”. 2.5 becomes 2, 3.5 becomes 4. And because the function operates on the binary double, round(0.125, 2) is not guaranteed to be 0.12 or 0.13 by the rule alone; it depends on whether 0.125 is represented exactly (it is) and how the algorithm handles the scaled value.

x <- c(0.5, 1.5, 2.5, -2.5, 0.125, 0.135, 2.675, 12.45)
data.frame(
  x,
  r_round   = round(x, 1),
  r_round2  = round(x, 2),
  sprintf_1 = sprintf("%.1f", x)
)

       x r_round r_round2 sprintf_1
1  0.500     0.5     0.50       0.5
2  1.500     1.5     1.50       1.5
3  2.500     2.5     2.50       2.5
4 -2.500    -2.5    -2.50      -2.5
5  0.125     0.1     0.12       0.1
6  0.135     0.1     0.14       0.1
7  2.675     2.7     2.67       2.7
8 12.450    12.4    12.45      12.4

Notice that sprintf() does not rescue you: it uses the C library’s formatting, which also rounds the binary value, and 2.675 prints as 2.67 because the stored double is slightly below 2.675.

Reproducing SAS rounding in R

The standard approach is to add a tiny tolerance and use floor() on the shifted absolute value, then restore the sign:

round_sas <- function(x, digits = 0, fuzz = 1e-9) {
  m <- 10^digits
  sign(x) * floor(abs(x) * m + 0.5 + fuzz) / m
}

data.frame(
  x,
  r_round   = round(x, 1),
  sas_round = round_sas(x, 1),
  r_round2  = round(x, 2),
  sas_round2 = round_sas(x, 2)
)

       x r_round sas_round r_round2 sas_round2
1  0.500     0.5       0.5     0.50       0.50
2  1.500     1.5       1.5     1.50       1.50
3  2.500     2.5       2.5     2.50       2.50
4 -2.500    -2.5      -2.5    -2.50      -2.50
5  0.125     0.1       0.1     0.12       0.13
6  0.135     0.1       0.1     0.14       0.14
7  2.675     2.7       2.7     2.67       2.68
8 12.450    12.4      12.5    12.45      12.45

The fuzz argument mirrors SAS’s behaviour of treating values within a tiny distance of a half as a half. Keep it small (1e-9 is conventional) and document it. Note that janitor::round_half_up() implements the same idea if you prefer a maintained dependency.

Where it bites in real tables

• Percentages in frequency tables. n / N * 100 with N = 8, 16, 40 or 80 produces exact halves at the first decimal. With N = 40, every odd count gives a .5.
• Means of integer scores. The mean of an even number of integers is often an exact half.
• Derived quantities such as BMI or change from baseline, where a two-stage rounding (derive, round, then summarise and round again) multiplies the opportunities for disagreement.
• Displayed vs stored values. SAS PUT() with a format rounds the displayed value; the dataset keeps full precision. If your R pipeline rounds before summarising, you will see differences that are not about rounding rules at all.

set.seed(1)
n <- c(3, 5, 7, 9, 11, 13, 15, 17)
N <- 40
pct <- n / N * 100
data.frame(n, pct, r = round(pct, 1), sas = round_sas(pct, 1), differ = round(pct, 1) != round_sas(pct, 1))

   n  pct    r  sas differ
1  3  7.5  7.5  7.5  FALSE
2  5 12.5 12.5 12.5  FALSE
3  7 17.5 17.5 17.5  FALSE
4  9 22.5 22.5 22.5  FALSE
5 11 27.5 27.5 27.5  FALSE
6 13 32.5 32.5 32.5  FALSE
7 15 37.5 37.5 37.5  FALSE
8 17 42.5 42.5 42.5  FALSE

Half of the odd counts disagree. In a 20-table package that is dozens of cells.

What to write in the tolerance document

Our migration tolerance rules usually contain three statements on rounding:

1. Rule used. “Displayed values are rounded half away from zero using round_sas() (package xyzmigr v1.2.0), matching SAS ROUND().” Or, after adoption, “rounded half to even using base R round()”; the point is that one rule is named.
2. Order of operations. Rounding happens once, at the display layer. Intermediate derivations keep full precision. Two-stage rounding is a documented exception.
3. Acceptance criterion. Numeric comparison of displayed values after applying the same rule on both sides must show zero differences; differences in the final displayed digit that are traceable to representation (e.g. 2.675) are logged as explained, not as deviations.

With those three lines, the reviewer sees a decision, not a surprise.

Should you keep SAS rounding forever?

During the parallel-run phase, yes: matching SAS is what makes the equivalence report clean. After adoption, many teams switch to R’s default and note the change in the SOP, because half-to-even is the IEEE standard and statistically unbiased. Either is acceptable; mixing both inside one submission is not.

Related reading: SAS to R migration roadmap, numerical tolerance rules for dual programming, and the SAS to R service page.