[Rd] s4 generic issue
John Chambers
jmc at r-project.org
Wed Nov 4 19:22:31 CET 2009
If you mean us to run the code you supplied:
1. There are two generic backsolve() functions, one in the gobal
environment and one in SparseM:
> showMethods(backsolve)
Function: backsolve (package .GlobalEnv)
r="ANY"
r="matrix"
(inherited from: r="ANY")
> showMethods(SparseM::backsolve)
Function: backsolve (package SparseM)
r="ANY"
r="matrix.csr.chol"
2. Package "lars" does not (unfortunately) have a NAMESPACE, so calls
from lars will get the version without a special method. This is
generally a recipe for trouble, but does not seem to be the issue in
this case.
3. A little inspection with options(error=recover) suggests the
computations screwed up some time before the actual call here (the
rather opaque error message is complaining because the x argument,
returned by backsolvet(), has NaNs and an Inf in it). Since
backsolvet() calls backsolve() with transpose=TRUE, it won't be happy
with your default method, which ignores the transpose= argument. Did
you really mean to do that? (Again, this would not show up in lars if
that package had a NAMESPACE).
I think the last point may explain your problem. It has nothing to do
with S4 generics, only with the general "keep it simple" advice.
Cheers,
John
Roger Koenker wrote:
> I'm hoping that someone with deeper insight into S4 than I,
> that is to say virtually everyone reading this list, could help
> resolve the following problem in SparseM. We have
>
> setGeneric("backsolve",
> function(r, x, k = NULL, upper.tri = NULL, transpose = NULL,
> twice = TRUE, ...)
> standardGeneric("backsolve"),
> useAsDefault= function(r, x, k = ncol(r), upper.tri = TRUE,
> transpose = FALSE, twice = TRUE, ...)
> base::backsolve(r, x, k = ncol(r), upper.tri = TRUE,
> transpose = FALSE, ...))
>
> and then proceed to use setMethod for a class matrix.csr.chol.
> However, this seems
> to cause problems in the following instance: if one does the following
>
> require(lars)
> require(SparseM)
> example(lars)
> ....[snip]
> lars> object3 <- lars(x,y,type="for") # Can use abbreviations
> Error in base::backsolve(r, x, k = ncol(r), upper.tri = TRUE,
> transpose = FALSE, :
> NA/NaN/Inf in foreign function call (arg 4)
> > traceback()
> 10: .C("bakslv", t = r, ldt = nrow(r), n = k, b = x, ldb = k, nb = nb,
> x = matrix(0, k, nb), job = job, info = integer(1L), DUP = FALSE,
> PACKAGE = "base")
> 9: base::backsolve(r, x, k = ncol(r), upper.tri = TRUE, transpose =
> FALSE,
> ...)
> 8: backsolve(R, backsolvet(R, Sign[positive]))
> 7: backsolve(R, backsolvet(R, Sign[positive]))
> 6: nnls.lars(active, Sign, R, directions, Gram[active, active],
> trace = trace, use.Gram = TRUE, eps = eps)
> 5: lars(x, y, type = "for")
> 4: eval.with.vis(expr, envir, enclos)
> 3: eval.with.vis(ei, envir)
> 2: source(zfile, local, echo = echo, prompt.echo = paste(prompt.prefix,
> getOption("prompt"), sep = ""), continue.echo =
> paste(prompt.prefix,
> getOption("continue"), sep = ""), verbose = verbose,
> max.deparse.length = Inf,
> encoding = encoding, skip.echo = skips, keep.source = TRUE)
> 1: example(lars)
>
> So clearly base::backsolve is getting called as would be desired in
> this case,
> but something is rotten in the way arguments are being passed.
>
> I'm aware that the R-extensions manual suggests another strategy than
> setGeneric for making generics, but I would like to understand what is
> going
> wrong here.
>
> Roger
>
>
> url: www.econ.uiuc.edu/~roger Roger Koenker
> email rkoenker at uiuc.edu Department of Economics
> vox: 217-333-4558 University of Illinois
> fax: 217-244-6678 Urbana, IL 61801
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
More information about the R-devel
mailing list