s4 generic issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

s4 generic issue

RKoenker
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    [hidden email]            Department of Economics
vox:     217-333-4558                University of Illinois
fax:       217-244-6678                Urbana, IL 61801

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: s4 generic issue

John Chambers-2
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    [hidden email]            Department of Economics
> vox:     217-333-4558                University of Illinois
> fax:       217-244-6678                Urbana, IL 61801
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel