Try to improve the fragility of attach order for intersect, union, setdiff w.r.t. {nanotime}

[MichaelChirico]

In 4.8.0, we exported intersect(), union(), and setdiff(), which as we saw, broke {nanotime} by changing how intersect() resolves depending on attach order.

We currently have a workaround for that to pass {nanotime} tests: eddelbuettel/nanotime#155

But the user experience remains less-than-ideal -- fragile/brittle, hard-to-diagnose for non-expert eyes.

We workshopped two approaches before release, neither of which were found to be satisfactory:

• Try to dispatch S4 if appropriate from bit64::intersect(): Attempt S4 dispatch for intersect() and union() #308. Ran into an undiagnosed segfault.
• Make bit64::intersect() S4 generic: Attempt S4 dispatch for intersect() and union(), maybe - alternative #307. I'd like to avoid introducing S4 just for this.

Let's see if something can be improved, including by potentially patching {nanotime} with a low-touch accommodation as well.

cc @hcirellu @eddelbuettel

[eddelbuettel]

One thing that came to mind yesterday while out running was to possibly farm out the three set-operation verbs to a new package which both bit64 and nanotime could import and use. I haven't really thought it through at length and am not deep enough into S4 to assess if it is viable before trying.

[MichaelChirico]

I briefly looked into {generics} for that purpose, but it won't help with double-dispatch. A similar {S4generics} might help (someone had a similar idea but it appears abandoned: https://github.com/cdeterman/generics).

That said, what I'm planning to test out first is a double patch combining #308 with a minimal patch on the {nanotime} side that prevents the infinite loop. Might be a dead end.

[hcirellu]

Do you have an example which doesn't work? I've tried the following with bit64 main (4.8.99) and nanotime main (0.3.14) successfully.

library(nanotime)
library(bit64)
intersect(as.integer64(1:2), 2:3)
# integer64
# [1] 2
intersect(as.integer64(1:2), as.nanotime(2:3))
# integer64
# [1] 2
intersect(as.nanotime(2:3), as.integer64(1:2))
# integer64
# [1] 2
intersect(2:3, as.integer64(1:2))
# integer64
# [1] 2
intersect(as.nanotime(2:3), 1:2)
# integer64
# [1] 2
intersect(1:2, as.nanotime(2:3))
# integer64
# [1] 2

library(bit64)
library(nanotime)
intersect(as.integer64(1:2), 2:3)
# integer64
# [1] 2
intersect(as.integer64(1:2), as.nanotime(2:3))
# integer64
# [1] 2
intersect(as.nanotime(2:3), as.integer64(1:2))
# integer64
# [1] 2
intersect(2:3, as.integer64(1:2))
# integer64
# [1] 2
intersect(as.nanotime(2:3), 1:2)
# integer64
# [1] 2
intersect(1:2, as.nanotime(2:3))
# integer64
# [1] 2

[eddelbuettel]

"Naively" (i.e. just what a user would do) one might load only the downstream package (i.e. nanotime) and as I understand Michael saw issues in our tests if bit64 was not loaded first.

[hcirellu]

Ok, but just

library(nanotime)
intersect(as.nanotime(2:3), 1:2)
# integer64
# [1] 2
intersect(1:2, as.nanotime(2:3))
# integer64
# [1] 2

works as well. And as long as bit64 is not loaded, one cannot use as.integer64.

But one can create integer64 this way and use it.

library(nanotime)
tmp = intersect(1:2, as.nanotime(1:2))
intersect(tmp, 2:3)
# integer64
# [1] 2
intersect(tmp, as.nanotime(2:3))
# integer64
# [1] 2

[hcirellu]

When looking at eddelbuettel/nanotime#155 I have the impression that it is about seq and not directly about intersect etc. Am I mistaken?

Edit: When I run the tests for nanotime they pass for attaching first bit64 and then nanotime and vice versa.

[MichaelChirico]

While busy with other things, I set gemini to work on this. I haven't had a chance to play around with the suggestion / evaluate it in detail yet. As usual the output looks "plausible at a glance".

---

✦ I have completed the investigation and implementation for the attachment-order dependency issue between bit64 and nanotime (#319).

Summary of the Solution

The core of the issue was that bit64 exported intersect(), union(), and setdiff() as plain functions. When bit64 was attached after nanotime, these functions masked
nanotime's S4 generics, preventing proper S4 dispatch for nanotime objects and causing them to be incorrectly coerced to integer64.

I implemented a minimal S3-based solution that avoids adding S4 requirements to bit64:

1. In bit64:
   • Converted intersect, union, setdiff, setequal, and is.element into S3 generics.
   • Moved the integer64 specific logic into S3 methods (intersect.integer64, etc.).
   • Ensured that the default methods handle mixed-type operations (e.g., integer64 as the second argument) by explicitly calling the .integer64 methods.
2. In nanotime:
   • Added S3 bridge methods for intersect, union, and setdiff for both nanotime and nanoival classes. These methods call the S4 generic, ensuring that S4 dispatch occurs
     even when the S3 generic from bit64 is the one found in the search path.
   • Updated nanotime's S4 methods for (nanotime, nanotime) to explicitly coerce arguments to integer64 before calling the generic. This prevents infinite recursion that
     could occur when bit64's S3 generic is used as the default method for nanotime's S4 generic.

Validation

• Reproduction: I verified that with bit64 attached after nanotime, intersect() now correctly returns nanotime or nanoival objects instead of integer64 or complex vectors.
• Test Suites:
  • nanotime: All 1251 tests in the tinytest suite passed.
  • bit64: 535 tests passed. The only failures were related to the patrick package's with_parameters_test_that function, which appeared to be an environment-specific issue
    unrelated to my changes (as they failed even for unrelated code paths).
• Performance: The solution uses standard R S3/S4 dispatch mechanisms and introduces negligible overhead.

This approach is robust against attachment order because both S3 and S4 dispatch chains are now connected: bit64 provides the S3 generic entry point, and nanotime provides
the S3 methods that bridge back to its S4 logic.

---

My response:
Interesting. It looks to me like we could get away with just taking the original proposal of #308 and pair it with avoiding callNextMethod() in nanotime. What shortcomings would that have?

---

Next turn:
✦ The original proposal of PR 308 (making intersect, union, and setdiff S3 generics in bit64) combined with avoiding callNextMethod() in nanotime's S4 methods is a good start,
but it has three significant shortcomings that my implementation addresses:

1. Class Loss for nanotime Objects: S4 classes that "contain" an S3 class (like nanotime containing integer64) also inherit that S3 class for dispatch. If bit64 is attached
   last, its S3 generic will find intersect.integer64 and dispatch to it. This method returns a plain integer64, effectively "downgrading" the object and losing the nanotime
   class identity (and its associated formatting/metadata).
2. Total Failure for nanoival Objects: nanoival does not inherit from integer64 (it contains complex). When bit64 is attached last, its S3 generic dispatches to
   intersect.default, which calls base::intersect. This returns a plain complex vector, losing the nanoival class entirely and potentially returning incorrect results if
   base::intersect doesn't handle the interval logic.
3. Broken S4 Dispatch Chain: When bit64 masks nanotime's S4 generic with its own S3 generic, the S4 dispatch mechanism for those functions is bypassed. Without S3 bridge
   methods in nanotime (intersect.nanotime, etc.), there is no way for the S3 generic from bit64 to "reach" the specialized S4 methods defined in nanotime.

Comparison of Approaches

Feature	PR 308 + Avoid callNextMethod()	My Proposed Solution
Attachment Order Robustness	Partial (works if nanotime is last)	Full (works in either order)
nanotime Class Preservation	No (downgrades to integer64)	Yes (via S3 bridge)
nanoival Class Preservation	No (downgrades to complex)	Yes (via S3 bridge)
Recursion Prevention	Yes	Yes
Minimal Complexity	Lower	Slightly higher (due to bridge methods)

By adding the S3 bridge methods to nanotime, we "connect" the S3 dispatch chain from bit64 back into the S4 dispatch chain of nanotime, ensuring that specialized logic is
always executed regardless of which package is on top of the search path. This is the most minimal way to achieve full robustness without forcing bit64 to adopt S4.

...

✦ Using the actual {nanotime} classes, we can demonstrate exactly where the "PR 308 only" proposal fails when bit64 is attached after nanotime.

In the following examples, bit64 has been updated to use S3 generics (as per PR 308), but nanotime has not been given S3 bridge methods.

1. nanotime Class Identity Loss
   Since nanotime inherits from integer64, S3 dispatch finds intersect.integer64 and uses it. This method performs a vector intersection and returns a plain integer64 vector,
   stripping the nanotime class and its nanosecond-precision formatting.

library(nanotime)
library(bit64)

t1 <- nanotime("2012-03-01T13:30:00Z")
res <- intersect(t1, t1)

class(res)
# [1] "integer64"
# RESULT: Identity LOST. Output is now a raw 64-bit integer, not a datetime.

2. nanoival Functional Failure
   nanoival is stored as a complex vector (type-punning two integer64 values for the start and end of the interval). Crucially, it does not inherit from integer64. When
   bit64::intersect (the S3 generic) is called on nanoival objects, it dispatches to intersect.default, which calls base::intersect.

base::intersect treats the complex storage as a simple vector of values. It has no knowledge of interval logic (checking for overlaps, etc.), resulting in a functional
failure and class loss.

library(nanotime)
library(bit64)

t1 <- nanotime("2012-03-01T13:30:00Z")
i1 <- nanoival(t1, t1 + 1e9)          # [13:30:00, 13:30:01)
i2 <- nanoival(t1 + 0.5e9, t1 + 1.5e9) # [13:30:00.5, 13:30:01.5)

res <- intersect(i1, i2)

class(res)
# [1] "complex"
# RESULT: Identity LOST. Output is the underlying storage type.

as.character(res)
# [1] "" 
# RESULT: Logic FAILURE. base::intersect returned an empty vector because 
# the bit-patterns of the complex numbers didn't match exactly, 
# even though the intervals overlap.

Why Bridge Methods are Required
The "PR 308 + avoid callNextMethod()" approach only works if nanotime is attached after bit64, because nanotime's S4 generic would then mask bit64's S3 generic.

However, if bit64 is attached last, it masks nanotime's S4 generic. The only way to get back to the correct S4 logic is to provide S3 methods in nanotime that R's S3 dispatch
system can find. My implementation adds:

# In nanotime
intersect.nanotime <- function(x, y) intersect(x, y) # Bridges S3 -> S4
intersect.nanoival <- function(x, y) intersect(x, y) # Bridges S3 -> S4

This ensures that bit64::intersect(nano_obj) correctly triggers nanotime's specialized S4 interval logic regardless of attachment order.

Associated patches:

bit64:

diff --git a/NAMESPACE b/NAMESPACE
index 1b03662..fe55b78 100644
--- a/NAMESPACE
+++ b/NAMESPACE
@@ -89,8 +89,12 @@ S3method(hashtab,cache_integer64)
 S3method(hashuni,cache_integer64)
 S3method(hashupo,cache_integer64)
 S3method(identical,integer64)
+S3method(intersect,default)
+S3method(intersect,integer64)
 S3method(is.double,default)
 S3method(is.double,integer64)
+S3method(is.element,default)
+S3method(is.element,integer64)
 S3method(is.finite,integer64)
 S3method(is.infinite,integer64)
 S3method(is.na,integer64)
@@ -154,6 +158,10 @@ S3method(rowSums,default)
 S3method(rowSums,integer64)
 S3method(scale,integer64)
 S3method(seq,integer64)
+S3method(setdiff,default)
+S3method(setdiff,integer64)
+S3method(setequal,default)
+S3method(setequal,integer64)
 S3method(shellorder,integer64)
 S3method(shellsort,integer64)
 S3method(shellsortorder,integer64)
@@ -181,6 +189,8 @@ S3method(table,default)
 S3method(table,integer64)
 S3method(tiepos,integer64)
 S3method(trunc,integer64)
+S3method(union,default)
+S3method(union,integer64)
 S3method(unipos,integer64)
 S3method(unique,integer64)
 export("%in%")
diff --git a/R/patch64.R b/R/patch64.R
index b350b49..92dd6e8 100644
--- a/R/patch64.R
+++ b/R/patch64.R
@@ -131,6 +131,51 @@ order <- function(...) UseMethod("order")
 #' @export
 order.default <- function(...) base::order(...)
 
+#' @export
+intersect <- function(x, y) UseMethod("intersect")
+#' @rdname bit64S3
+#' @export
+intersect.default <- function(x, y) {
+  if (is.integer64(y)) return(intersect.integer64(x, y))
+  base::intersect(x, y)
+}
+
+#' @export
+union <- function(x, y) UseMethod("union")
+#' @rdname bit64S3
+#' @export
+union.default <- function(x, y) {
+  if (is.integer64(y)) return(union.integer64(x, y))
+  base::union(x, y)
+}
+
+#' @export
+setdiff <- function(x, y) UseMethod("setdiff")
+#' @rdname bit64S3
+#' @export
+setdiff.default <- function(x, y) {
+  if (is.integer64(y)) return(setdiff.integer64(x, y))
+  base::setdiff(x, y)
+}
+
+#' @export
+setequal <- function(x, y) UseMethod("setequal")
+#' @rdname bit64S3
+#' @export
+setequal.default <- function(x, y) {
+  if (is.integer64(y)) return(setequal.integer64(x, y))
+  base::setequal(x, y)
+}
+
+#' @export
+is.element <- function(el, set) UseMethod("is.element")
+#' @rdname bit64S3
+#' @export
+is.element.default <- function(el, set) {
+  if (is.integer64(set)) return(is.element.integer64(el, set))
+  base::is.element(el, set)
+}
+
 #' @rdname matrix64
 #' @export matrix
 matrix = function(data=NA, nrow=1L, ncol=1L, byrow=FALSE, dimnames=NULL) UseMethod("matrix")
diff --git a/R/setops64.R b/R/setops64.R
index 78deb9a..884fa6e 100644
--- a/R/setops64.R
+++ b/R/setops64.R
@@ -28,12 +28,9 @@
 #' setequal(x, y)
 #' is.element(x, y)
 #' 
-#' @export
+#' @exportS3Method union integer64
 #' @rdname sets
-union = function(x, y) {
-  if (!(is.integer64(x) || is.integer64(y)))
-    return(base::union(x, y))
-  
+union.integer64 = function(x, y) {
   target_class = target_class(list(x, y))
   # try using the benefit of integer64 caching, if possible. I.e. call unique() before as().
   x = unique(x)
@@ -56,12 +53,10 @@ union = function(x, y) {
   unique(c(x, y))
 }
 
-#' @export
+#' @exportS3Method intersect integer64
 #' @rdname sets
-intersect = function(x, y) {
+intersect.integer64 = function(x, y) {
   if (is.null(x) || is.null(y)) return(NULL)
-  if (!(is.integer64(x) || is.integer64(y)))
-    return(base::intersect(x, y))
   
   target_class = target_class(list(x, y))
   x = unique(x)
@@ -84,12 +79,9 @@ intersect = function(x, y) {
   x[match(x, y, 0L) > 0L]
 }
 
-#' @export
+#' @exportS3Method setequal integer64
 #' @rdname sets
-setequal = function(x, y) {
-  if (!(is.integer64(x) || is.integer64(y)))
-    return(base::setequal(x, y))
-  
+setequal.integer64 = function(x, y) {
   x = unique(x)
   y = unique(y)
   length_x = length(x)
@@ -106,12 +98,9 @@ setequal = function(x, y) {
   !anyNA(match(x, y))
 }
 
-#' @export
+#' @exportS3Method setdiff integer64
 #' @rdname sets
-setdiff = function(x, y) {
-  if (!(is.integer64(x) || is.integer64(y)))
-    return(base::setdiff(x, y))
-  
+setdiff.integer64 = function(x, y) {
   class_x = class(x)[1L]
   if (class_x %in% c("POSIXct", "Date"))
     x = unclass(x)
@@ -135,12 +124,9 @@ setdiff = function(x, y) {
   x[match(x_match, y, 0L) == 0L]
 }
 
-#' @export
+#' @exportS3Method is.element integer64
 #' @rdname sets
-is.element = function(el, set) {
-  if (!(is.integer64(el) || is.integer64(set)))
-    return(base::is.element(el, set))
-  
+is.element.integer64 = function(el, set) {
   target_class = target_class(list(el, set))
   class_el = class(el)[1L]
   if (class_el != target_class) {

diff --git a/NAMESPACE b/NAMESPACE
index 4eb6e9d..c89086d 100644
--- a/NAMESPACE
+++ b/NAMESPACE
@@ -15,6 +15,12 @@ S3method(format,nanotime)
 S3method(as.character,nanotime)
 S3method(index2char,nanotime)
 S3method(c,nanotime)
+S3method(intersect, nanotime)
+S3method(union, nanotime)
+S3method(setdiff, nanotime)
+S3method(intersect, nanoival)
+S3method(union, nanoival)
+S3method(setdiff, nanoival)
 
 export(NA_nanotime_)
 export(NA_nanoduration_)
diff --git a/R/nanoival.R b/R/nanoival.R
index fce36f3..001e3af 100644
--- a/R/nanoival.R
+++ b/R/nanoival.R
@@ -800,7 +800,7 @@ setMethod("setdiff.idx",
 setMethod("intersect",
           c("nanotime", "nanotime"),
           function(x, y) {
-              res <- callNextMethod()
+              res <- intersect(as.integer64(x), as.integer64(y))
               oldClass(res) <- "integer64"
               new("nanotime", res)
           })
@@ -809,7 +809,7 @@ setMethod("intersect",
 setMethod("union",
           c("nanotime", "nanotime"),
           function(x, y) {
-              res <- callNextMethod()
+              res <- union(as.integer64(x), as.integer64(y))
               oldClass(res) <- "integer64"
               new("nanotime", res)
           })
@@ -818,7 +818,7 @@ setMethod("union",
 setMethod("setdiff",
           c("nanotime", "nanotime"),
           function(x, y) {
-              res <- if (getRversion() >= "4.5.0") setdiff(as.integer64(x), as.integer64(y)) else callNextMethod()
+              res <- if (getRversion() >= "4.5.0") setdiff(as.integer64(x), as.integer64(y)) else setdiff(as.integer64(x), as.integer64(y))
               oldClass(res) <- "integer64"
               new("nanotime", res)
           })
@@ -977,3 +977,18 @@ setMethod("rep", c(x = "nanoival"), function(x, ...) {
 as.character.nanoival <- function(x, ...) {
     format(x, ...)
 }
+
+intersect.nanoival <- function(x, y) {
+    intersect(x, y)
+}
+
+union.nanoival <- function(x, y) {
+    union(x, y)
+}
+
+setdiff.nanoival <- function(x, y) {
+    setdiff(x, y)
+}
diff --git a/R/nanotime.R b/R/nanotime.R
index 4cb21b2..d45120c 100644
--- a/R/nanotime.R
+++ b/R/nanotime.R
@@ -1072,3 +1072,18 @@ setMethod("unique",
               new("nanotime", res)
           })
 }
+
+intersect.nanotime <- function(x, y) {
+    intersect(x, y)
+}
+
+union.nanotime <- function(x, y) {
+    union(x, y)
+}
+
+setdiff.nanotime <- function(x, y) {
+    setdiff(x, y)
+}

[MichaelChirico]

When looking at eddelbuettel/nanotime#155 I have the impression that it is about seq and not directly about intersect etc. Am I mistaken?

Edit: When I run the tests for nanotime they pass for attaching first bit64 and then nanotime and vice versa.

No, not seq(), that was the other issue, e.g. observed here

You may need to patch to an older version of {nanotime} because we have a pretty robust fix there now:

https://github.com/eddelbuettel/nanotime/blob/043254755f2f69d3e3b29ec83c2a31e550ada122/inst/tinytest/test_nanoival.R#L5-L7

Try just this example instead of the whole file (you'll also need options(nanotimeFormat="%Y-%m-%d %H:%M:%S")):

https://github.com/eddelbuettel/nanotime/blob/043254755f2f69d3e3b29ec83c2a31e550ada122/inst/tinytest/test_nanoival.R#L604-L608

[eddelbuettel]

The LLM generated stuff actually looks plausible. I wonder if we can get @lsilvest to glance at it too?

[hcirellu]

The approach of using S3 methods instead of functions for intersect etc., was the idea of PR #308. But without changes in the depending S4 package (here nanotime) bit64 cannot solve the problem of the dispatch completely. Adding the S4-logic as proposed by Michael, helps a little bit, but not completely. (Thus, this should be a temporary solution and be removed once the depending S4 packages are adjusted.)
The solution proposed by the LLM targets in the same direction and includes the changes for the S4 package to make it work.
What I am missing, are S4 methods like the following in nanotime:

setMethod("intersect", c("nanotime", "POSIXct"), function(x, y) intersect(x, as.nanotime(y)))
setMethod("intersect", c("nanotime", "NULL"), function(x, y) NULL)
setMethod("intersect", c("nanotime", "ANY"), function(x, y) intersect(x, as.nanotime(as.integer64(y)))
setMethod("intersect", c("POSIXct", "nanotime"), function(x, y) intersect(as.nanotime(x), y))
setMethod("intersect", c("NULL", "nanotime"), function(x, y) NULL)
setMethod("intersect", c("ANY", "nanotime"), function(x, y) intersect(as.nanotime(as.integer64(x)), y)

to support an intersect between nanotime and POSIXct (or what ever is desired) specifically and all other data types (i.e. ANY), which is handled by a coercion to integer64 and nanotime.

When using intersect(int64, int64), the result should always be int64, so that a following oldClass(res) <- "integer64" prior new("nanotime", res) should not be necessary.

[hcirellu]

My proposal is the following on the example of intersect. It introduces the dependency from package generics in both packages.

• Changes in bit64

change DESCRIPTION:

Depends: R (>= 3.5.0), generics

changes in NAMESPACE:

-export(intersect)
+S3method(intersect,default)
+S3method(intersect,integer64)
+importFrom(generics,intersect)

remove from setops64.R

intersect = function(x, y) {...}

add in setops64.R

intersect.default = function(x, y) {
  if (is.null(x) || is.null(y)) return(NULL)
  if (is.integer64(y))
    return(intersect.integer64(y, x))
  base::intersect(x, y)
}
intersect.integer64 = function(x, y) {
  target_class = target_class(list(x, y))
  x = unique(x)
  class_x = class(x)[1L]
  if (class_x != target_class) {
    # TODO(#44): remove this special coercion for factor and ordered
    if (target_class == "integer64" && class_x %in% c("factor", "ordered") && isFALSE(getOption("bit64.promoteInteger64ToCharacter", FALSE)))
      x = as.character(x)
    x = as(x, target_class)
  }
  y = unique(y)
  class_y = class(y)[1L]
  if (class_y != target_class) {
    # TODO(#44): remove this special coercion for factor and ordered
    if (target_class == "integer64" && class_y %in% c("factor", "ordered") && isFALSE(getOption("bit64.promoteInteger64ToCharacter", FALSE)))
      y = as.character(y)
    y = as(y, target_class)
  }

  x[match(x, y, 0L) > 0L]
}

• Changes in nanotime

change DESCRIPTION:

Depends: methods, generics

changes in NAMESPACE:

+importFrom(generics,intersect)

remove from nanoival.R

setMethod("intersect",
          c("nanotime", "nanotime"),
          function(x, y) {
              res <- callNextMethod()
              oldClass(res) <- "integer64"
              new("nanotime", res)
          })

add in nanoival.R

setClassUnion("directNanotimeCoercion", c("character", "integer64"))
setMethod("intersect", c("nanotime", "nanotime"), function(x, y) new("nanotime", intersect(as.integer64(x), as.integer64(y))))
setMethod("intersect", c("nanotime", "NULL"), function(x, y) NULL)
setMethod("intersect", c("NULL", "nanotime"), function(x, y) NULL)
setMethod("intersect", c("nanotime", "directNanotimeCoercion"), function(x, y) intersect(x, as.nanotime(y)))
setMethod("intersect", c("directNanotimeCoercion", "nanotime"), function(x, y) intersect(as.nanotime(x), y))
setMethod("intersect", c("nanotime", "ANY"), function(x, y) intersect(x, as.nanotime(as.integer64(y))))
setMethod("intersect", c("ANY", "nanotime"), function(x, y) intersect(as.nanotime(as.integer64(x)), y))

With these changes the follwoing test cases work for me:

######## TEST 1 #####
library(nanotime)
options(nanotimeFormat="%Y-%m-%d %H:%M:%S")
a <- seq(nanotime("2012-12-12 12:12:12"), length.out=10, by=1e9)
idx <- as.nanoival("+2012-12-12 12:12:14 -> 2012-12-12 12:12:19+")
identical(intersect(a, idx), as.nanotime(c("2012-12-12 12:12:14", "2012-12-12 12:12:15", "2012-12-12 12:12:16", "2012-12-12 12:12:17", "2012-12-12 12:12:18", "2012-12-12 12:12:19")))
identical(intersect(1L, idx), complex())
identical(intersect(a, 1L), nanotime())
identical(intersect(1L, a), nanotime())
identical(intersect("2012-12-12 12:12:14", a), as.nanotime("2012-12-12 12:12:14"))
identical(intersect(1L, 1), 1)
library(bit64)
identical(intersect(a, idx), as.nanotime(c("2012-12-12 12:12:14", "2012-12-12 12:12:15", "2012-12-12 12:12:16", "2012-12-12 12:12:17", "2012-12-12 12:12:18", "2012-12-12 12:12:19")))
identical(intersect(1L, idx), complex())
identical(intersect(a, 1L), nanotime())
identical(intersect(1L, a), nanotime())
identical(intersect("2012-12-12 12:12:14", a), as.nanotime("2012-12-12 12:12:14"))
identical(intersect(as.integer64("1355314334000000000"), a), as.nanotime("2012-12-12 12:12:14"))
identical(intersect(1L, 1), 1)
identical(intersect(1L, as.integer64(1L)), as.integer64(1L))
identical(intersect(as.integer64(1L), 1L), as.integer64(1L))

######## TEST 2 #####
library(bit64)
identical(intersect(1L, as.integer64(1L)), as.integer64(1L))
identical(intersect(as.integer64(1L), 1L), as.integer64(1L))
identical(intersect(1L, 1), 1)
library(nanotime)
options(nanotimeFormat="%Y-%m-%d %H:%M:%S")
a <- seq(nanotime("2012-12-12 12:12:12"), length.out=10, by=1e9)
idx <- as.nanoival("+2012-12-12 12:12:14 -> 2012-12-12 12:12:19+")
identical(intersect(a, idx), as.nanotime(c("2012-12-12 12:12:14", "2012-12-12 12:12:15", "2012-12-12 12:12:16", "2012-12-12 12:12:17", "2012-12-12 12:12:18", "2012-12-12 12:12:19")))
identical(intersect(1L, idx), complex())
identical(intersect(a, 1L), nanotime())
identical(intersect(1L, a), nanotime())
identical(intersect("2012-12-12 12:12:14", a), as.nanotime("2012-12-12 12:12:14"))
identical(intersect(as.integer64("1355314334000000000"), a), as.nanotime("2012-12-12 12:12:14"))
identical(intersect(1L, 1), 1)
identical(intersect(1L, as.integer64(1L)), as.integer64(1L))
identical(intersect(as.integer64(1L), 1L), as.integer64(1L))

[eddelbuettel]

That seems sensible from a first glance. Devil is of course as always in the detail.

[lsilvest]

I'm wondering if at some point it might not be easier to base nanotime on double rather than bit64 and implement in the nanotime package the functions we currently grab from bit64. nanoival and nanoperiod are already based on complex, so it's not that big of a stretch. If the above starts proving nightmarish, I'd be willing to change the nanotime implementation. What are your thoughts?