How to distinguish M[2, ] from M[2]? - r

Question

I defined some S4 matrices, whose class is lazyMatrix. If M is such a matrix, I want to define M[2, ] as the second row of M, and M[2] as the second coefficient of M (when enumerating the coefficients column after column).
So I defined these two S4 methods:
setMethod( # to extract a coefficient
"[",
signature("lazyMatrix", i = "numeric"),
function(x, i) {
......
}
)
setMethod( # to extract a row
"[",
signature("lazyMatrix", i = "numeric", j = "missing", drop = "ANY"),
function(x, i, j, drop) {
......
}
)
But both M[2, ] and M[2] return the second row of M. I tried to exchange the order of the two method definitions, that does not change anything.

Answer 1

I found a solution in the source code of the onion package:
setMethod(
"[",
signature("lazyMatrix", i = "numeric", j = "missing", drop = "missing"),
function(x, i, j, ..., drop) {
n_args <- nargs()
if(n_args == 3L) { # M[i, ]
......
} else if(n_args == 2L) { # M[i]
......
} else {
stop("Invalid arguments in subsetting.")
}
}
)
setMethod(
"[",
signature("lazyMatrix", i = "numeric", j = "missing", drop = "ANY"),
function(x, i, j, ..., drop) {
n_args <- nargs()
if(n_args == 4L) { # M[i, ]
......
} else if(n_args == 3L) { # M[i]
......
} else {
stop("Invalid arguments in subsetting.")
}
}
)
Before finding this solution, I tried using nargs() in my attempts, unsuccessfully. The trick is to add the ... argument. But I don't understand how this works. Please leave another answer or a comment if you can explain.

Answer 2

The dispatch issue has nothing to do with the dots, though it is problematic that the formal arguments of your methods do not match those of the generic function:
> getGeneric("[")
standardGeneric for "[" defined from package "base"
function (x, i, j, ..., drop = TRUE)
standardGeneric("[", .Primitive("["))
<bytecode: 0x1403d1a28>
<environment: 0x1403c9d10>
Methods may be defined for arguments: x, i, j, drop
Use showMethods([) for currently available ones.
?setMethod is quite clear about that:
The definition must be a function with the same formal arguments as the generic; however, setMethod() will handle methods that add arguments, if ... is a formal argument to the generic. See the Details section.
Anyway, the real issue is that setMethod interprets your first signature
signature("lazyMatrix", i = "numeric")
as
signature("lazyMatrix", i = "numeric", j = "ANY", drop = "ANY")
and both of the calls M[2] and M[2, ] match your second signature
signature("lazyMatrix", i = "numeric", j = "missing", drop = "ANY")
more closely than the first (because "missing" is more specific than "ANY"). Hence dispatch in both cases favours the second method.
It is still true that the primitive function [ is the trickiest generic function out there, due to all of the special cases handled in C code for traditional matrices (of implicit class matrix). The nargs() approach is correct and also used by package Matrix, which is really the canonical reference for this kind of thing:
> library(Matrix)
> selectMethod("[", signature = c("Matrix", "numeric", "missing", "missing"))
Method Definition:
function (x, i, j, ..., drop = TRUE)
{
Matrix.msg("M[i,m,m] : nargs()=", nargs(), .M.level = 2)
if (nargs() == 2) {
.M.vectorSub(x, i)
}
else {
callGeneric(x, i = i, , drop = TRUE)
}
}
<bytecode: 0x128e94a90>
<environment: namespace:Matrix>
Signatures:
x i j drop
target "Matrix" "numeric" "missing" "missing"
defined "Matrix" "index" "missing" "missing"