I came across the following result that seems very un-intuitive to me:
library(bit64)
x = as.integer64(200)
y = as.integer64(300)
min(x, y)
integer64
[1] 300
min.integer64(x, y)
integer64
[1] 300
Surely there is something obvious that I do not get but can someone point it out to me ?
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)
Matrix products: default
BLAS: /usr/lib64/libblas.so.3.4.2
LAPACK: /usr/lib64/liblapack.so.3.4.2
locale:
[1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C
[3] LC_TIME=en_US.utf8 LC_COLLATE=en_US.utf8
[5] LC_MONETARY=en_US.utf8 LC_MESSAGES=en_US.utf8
[7] LC_PAPER=en_US.utf8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] bit64_0.9-7 bit_1.1-14
loaded via a namespace (and not attached):
[1] compiler_3.6.1
I am sorry, but this is simply a bug. I should have known better and am already fixing it. Unfortunately my next bundle of deplyoments for packages 'bit','bit64','ff' involves a interface change in package 'bit' regarding class 'bitwhich'. This implies (after testing is completed) announcing the interface change to R-package-devel and wait 4 weeks until deployment to CRAN. Hence you get the fixes faster from r-forge (where it is not yet). I let you know here once the fix is on r-forge. Kind regards Jens