search

pharmaverse / blog

Blogging on the latest, greatest and most spectacular stuff happening around the pharmaverse
https://pharmaverse.github.io/blog/
Apache License 2.0
21 stars 9 forks source link

Closes #71 rounding #72

Closed kaz462 closed 1 year ago

bms63 commented 1 year ago

CAn we increase the description here. Feels kind of empty image

bms63 commented 1 year ago

I think we might want to mention SAS's rounde function, which matches R's round function

bms63 commented 1 year ago

It might be nice to give this PHUSE working group more of a shout out! A cross-industry initiative to document differences between programming languages.

image

bms63 commented 1 year ago

SO I first encountered this issue when double programming in R for TLGs made in SAS. I think you experienced the same issue and I think that should be mentioned here to set the stage.

image

bms63 commented 1 year ago

Maybe change this to Exploring Rounding Options. Bug Fix makes it seem like R is doing something wrong and SAS is doing it right.
image

bms63 commented 1 year ago

The post just sort of ends abruptly - anyway we could tie it up with your current experiences/summary of the post?

This one is going to be awesome!!!

kaz462 commented 1 year ago

Maybe change this to Exploring Rounding Options. Bug Fix makes it seem like R is doing something wrong and SAS is doing it right. image

what do you think of changing "Bug Fix" to "Numerical precision issue"? I also linked a SAS documentation on this topic: Numerical Accuracy in SAS Software

kaz462 commented 1 year ago

@manciniedoardo @bms63 Thanks so much for your review and comments!

I have limited knowledge on computational precision and floating-point, so I didn't go too deep on this topic, let me know if everything makes sense by referencing multiple resources.

kaz462 commented 1 year ago

Perhaps leave them with a question at the end of the post. How concerned should we be if a programs in R and and SAS are off ...

Good idea on the open-ended question. The following example illustrate the "safe" options I mentioned in the last section doesn't work as expected, but I'm not sure if this will ever happen in our daily work.

In this example, a is a value slightly less than 1.5. So if we choose round half up approach with 0 decimal places, output 1 is expected, but because + sqrt(.Machine$double.eps) is used, we get 2 as the result. 

> a <- 1.5 - 0.5*sqrt(.Machine$double.eps)
> janitor::round_half_up(a, digits = 0)
[1] 2

If it happens, maybe we could argue a and 1.5 are nearly equal by using all.equal() function from base R with default tolerance value (default tolerance = sqrt(.Machine$double.eps) 

> all.equal(a, 1.5)
[1] TRUE

@manciniedoardo @rossfarrugia @bms63 depends on the situation, maybe discrepancies like this example can be accepted? should I add this example in the last section?

rossfarrugia commented 1 year ago

Fine from my side 👍