Rounding

Rounding methods

Both SAS and base R have the function round(), which rounds the input to the specified number of decimal places. However, they use different approaches when rounding off a 5:

• SAS round() rounds half up. This is the most common method of rounding.

• base R round() rounds to the nearest even. Therefore round(0.5) is 0 and round(-1.5) is -2. Note from the base R round documentation:

  • this is dependent on OS services and on representation error (since e.g. 0.15 is not represented exactly, the rounding rule applies to the represented number and not to the printed number, and so round(0.15, 1) could be either 0.1 or 0.2).

Although base R does not have the option for “round half up”, there are functions available in other R packages (e.g., janitor, tidytlg).

In general, there are many often used rounding methods. In the table below, you can find examples of them applied to the number 1.45.

	round half up	round to even	round up	round down	round towards zero
Example: 1.45	1.5 (round to 1 decimal place)	1.4 (round to 1 decimal place)	2	1	1

Here are the corresponding ways to implement these methods in SAS and R.

	round half up	round to even	round up	round down	round towards zero
SAS	round()	rounde()	ceil()	floor()	int()
R	janitor::round_half_up() tidytlg::roundSAS()	base::round()	base::ceiling()	base::floor()	base::trunc()

This table is summarized from links below, where more detailed discussions can be found -

• Two SAS blogs about round-to-even and rounding-up-rounding-down

• R documentation: Base R Round, janitor::round_half_up(), tidytlg::roundSAS()

• CAMIS (Comparing Analysis Method Implementations in Software): A cross-industry initiative to document discrepant results between software. Rounding is one of the comparisons, and there are much more on this page!

Round half up in R

The motivation for having a ‘round half up’ function is clear: it’s a widely used rounding method, but there are no such options available in base R.

There are multiple forums that have discussed this topic, and quite a few functions already available. But which ones to choose? Are they safe options?

The first time I needed to round half up in R, I chose the function from a PHUSE paper and applied it to my study. It works fine for a while until I encountered the following precision issue when double programming in R for TLGs made in SAS.

Numerical precision issue

Example of rounding half up for 2436.845, with 2 decimal places:

# a function that rounds half up
# exact copy from: https://www.lexjansen.com/phuse-us/2020/ct/CT05.pdf
ut_round <- function(x, n = 0) {
  # x is the value to be rounded
  # n is the precision of the rounding
  scale <- 10^n
  y <- trunc(x * scale + sign(x) * 0.5) / scale
  # Return the rounded number
  return(y)
}
# round half up for 2436.845, with 2 decimal places
ut_round(2436.845, 2)

[1] 2436.84

The expected result is 2436.85, but the output rounds it down. Thanks to the community effort, there are already discussions and resolution available in a StackOverflow post -

There are numerical precision issues, e.g., round2(2436.845, 2) returns 2436.84. Changing z + 0.5 to z + 0.5 + sqrt(.Machine$double.eps) seems to work for me. – Gregor Thomas Jun 24, 2020 at 2:16

• .Machine$double.eps is a built-in constant in R that represents the smallest positive floating-point number that can be represented on the system (reference: Machine Characteristics)

• The expression + sqrt(.Machine$double.eps) is used to add a very small value to mitigate floating-point precision issues.

• For more information about computational precision and floating-point, see the following links -

  • R: Why doesn’t R think these numbers are equal?
  • SAS: Numerical Accuracy in SAS Software

After the fix:

# revised rounds half up
ut_round1 <- function(x, n = 0) {
  # x is the value to be rounded
  # n is the precision of the rounding
  scale <- 10^n
  y <- trunc(x * scale + sign(x) * 0.5 + sqrt(.Machine$double.eps)) / scale
  # Return the rounded number
  return(y)
}
# round half up for 2436.845, with 2 decimal places
ut_round1(2436.845, 2)

[1] 2436.85

We are not alone

The same issue occurred in the following functions/options as well, and has been raised by users:

• janitor::round_half_up(): issue was raised and fixed in v2.1.0

• Tplyr: options(tplyr.IBMRounding = TRUE), issue was raised

• scrutiny::round_up_from()/round_up(): issue was raised and fixed

• ... and many others!

Which ones to use?

The following functions have the precision issue mentioned above fixed, they all share the same logic from this StackOverflow post.

• janitor::round_half_up() version >= 2.1.0
• tidytlg::roundSAS()
  • this function has two more arguments that can convert the result to character and allow a character string to indicate missing values
• scrutiny::round_up_from()/round_up() version >= 0.2.5

  • round_up_from() has a threshold argument for rounding up, which adds flexibility for rounding up

  • round_up() rounds up from 5, which is a special case of round_up_from()

Are they safe options?

Those “round half up” functions do not offer the same level of precision and accuracy as the base R round function.

For example, let’s consider a value a that is slightly less than 1.5. If we choose round half up approach to round a to 0 decimal places, an output of 1 is expected. However, those functions yield a result of 2 because 1.5 - a is less than sqrt(.Machine$double.eps).

a <- 1.5 - 0.5 * sqrt(.Machine$double.eps)
ut_round1(a, 0)

[1] 2

janitor::round_half_up(a, digits = 0)

[1] 2

This behavior aligns the floating point number comparison functions all.equal() and dplyr::near() with default tolerance .Machine$double.eps^0.5, where 1.5 and a are treated as equal.

all.equal(a, 1.5)

[1] TRUE

dplyr::near(a, 1.5)

[1] TRUE

We can get the expected results from base R round as it provides greater accuracy.

round(a)

[1] 1

Here is an example when base R round reaches the precision limit:

# b is slightly less than 1.5
b <- 1.5 - 0.5 * .Machine$double.eps
# 1 is expected but the result is 2
round(b)

[1] 2

The precision and accuracy requirements can vary depending on the application. Therefore, it is essential to be aware each function’s performance in your specific context before making a choice.

Conclusion

With the differences in default behaviour across languages, you could consider your QC strategy and whether an acceptable level of fuzz in the electronic comparisons could be allowed for cases such as rounding when making comparisons between 2 codes written in different languages as long as this is documented. Alternatively you could document the exact rounding approach to be used in the SAP and then match this regardless of programming language used. - Ross Farrugia

Thanks Ross Farrugia, Ben Straub, Edoardo Mancini and Liming for reviewing this blog post and providing valuable feedback!

If you spot an issue or have different opinions, please don’t hesitate to raise them through pharmaverse/blog!

Last updated

2024-11-15 19:39:46.048884

Details

Source, Session info