Why does min(200, 300) returns 300 for integer64 class

Question

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

Numerable

Interstingly this works: min(c(x,y)) will give 200 – Nowhither

and pmin(x,y) too – Numerable

there's a separate min.integer64, since min is a primitive function so it can't use methods. Still doesn't explain the outcome of min in this situation, though... – Wolgast

looking at ?min in Note: it might be the explanation (not sure I understand it right though) – Numerable

I was wondering about that too - does it mean min/max DON'T work with S3/S4, or just that pmin/pmax can ALSO work with them? not clear. – Wolgast

The documentation clearly says that min is a (S3) generic. – Fides

Answer 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

Sulfathiazole

Hello @Jens Oehlschlägel cran version of bit64 still is 0.9-7 would that be possible to fix the bellow bug and bump to 0.9-8 ? Do you have a version on github or similar so I can send you a PR maybe ? – Numerable

Answer 2

I'm pretty sure that this is a bug. Please report it to the package maintainer.

If I slightly change the definition of min.integer64, it works correctly:

assignInNamespace("min.integer64",
function (..., na.rm = FALSE) 
{
  l <- list(...)
  ret <- double(1)
  noval <- TRUE
  if (length(l) == 1) {
    if (length(l[[1]])) 
      noval <- FALSE
    .Call(bit64:::C_min_integer64, l[[1]], na.rm, ret)
    oldClass(ret) <- "integer64"
  }
  else {
    ret <- sapply(l, function(e) {
      if (length(e)) 
        noval <<- FALSE
      if (is.integer64(e)) {
        ret <- double(1) #this was missing
        .Call(bit64:::C_min_integer64, e, na.rm, ret)
        ret
      }
      else {
        as.integer64(min(e, na.rm = na.rm))
      }
    })
    oldClass(ret) <- "integer64"
    ret <- min(ret, na.rm = na.rm)
  }
  if (noval) 
    warning("no non-NA value, returning +9223372036854775807")
  ret
}, pos = "package:bit64")

min(x, y)
#integer64
#[1] 200
min(y, x)
#integer64
#[1] 200

Fides

I pinged the maintainer by email, let's wait and see – Numerable