Exploration of some commonly used rounding methods and their corresponding functions in SAS and R, with a focus on ‘round half up’ and reliable solutions for numerical precision challenges.
Technical
Author
Kangjie Zhang
Published
August 22, 2023
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:
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).
Other common methods include:
Rounding half up, where, as the name suggests, a 5 always gets rounded up. In base R, there are no functions that implement this method natively, however there are functions available in other R packages (e.g., janitor, tidytlg).
Rounding towards zero, which is the opposite of rounding away from zero.
As the list above shows, there are many options to choose from when looking to round a number. In the table below, you can find examples of some of these 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 -
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.pdfut_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 numberreturn(y)}# round half up for 2436.845, with 2 decimal placesut_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 -
# revised rounds half uput_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 numberreturn(y)}# round half up for 2436.845, with 2 decimal placesut_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.
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.5b <-1.5-0.5* .Machine$double.eps# 1 is expected but the result is 2round(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!