[R-pkg-devel] Creating S3 methods for S4 classes
Dear all,
per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.
I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:
setGeneric("predict")
setMethod("predict", "ANY", stats::predict)
I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach
It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.
Any thoughts?
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Creating S3 methods for S4 classes
Dear Joris,
in my eyes, this is clearly a Q that should be asked on R-devel,
not R-package-devel ...
> Joris Meys
> on Thu, 24 May 2018 14:17:07 +0200 writes:
> Dear all, per the manual, one should create and register
> both the S3 and a S4 method if one needs a method for an
> S4 class for a function using S3 dispatching. This is
> cumbersome, and not very optimal.
> I was wondering if there's a better way to do
> this. Currently I recreate a generic in my package and
> create a default method that sends all the other classes
> to the S3 generic, eg:
> setGeneric("predict") setMethod("predict", "ANY",
> stats::predict)
> I'm not sure if this hasn't any adverse consequences, as
> it is not the recommended approach
> It would be great if these generics could be made
> available through stats4. If this would be the prefered
> route, I volunteer to create the patch for that.
> Any thoughts? Cheers Joris
> --
> Joris Meys Statistical consultant
> Department of Data Analysis and Mathematical Modelling
> Ghent University Coupure Links 653, B-9000 Gent (Belgium)
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> [[alternative HTML version deleted]]
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Creating S3 methods for S4 classes
My understanding is that the S3 methods guard against situations where only S3
dispatch is done,
e.g. by some internal generics. It may well be that for 'predict' this is not
theoretical possibility.
I second your suggestion about predict and stats4. I have wondered in the past
why 'predict' has been left out of stats4.
Georgi Boshnakov
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Joris Meys
Sent: 24 May 2018 13:17
To: R Package Development
Subject: [R-pkg-devel] Creating S3 methods for S4 classes
Dear all,
per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.
I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:
setGeneric("predict")
setMethod("predict", "ANY", stats::predict)
I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach
It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.
Any thoughts?
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Creating S3 methods for S4 classes
Hi Joris,
At least some aspects of this topic are of interest on this list, given its
complexity.
I think that your example:
setGeneric("predict")
setMethod("predict", "ANY", stats::predict)
creates a new function 'predict' in your namespace, it doesn't make
stats::predict S4 generic. This is fine when your 'predict' is visible
but when it is not, stats::predict will be called.
So, for classes for which you define methods for predict, what happens may
depend on whether or not your package is attached.
On the other hand, S3 methods defined for predict, will be used (if exported)
as long as the package is attached.
I may be wrong but for this or similar reasons I believe that 'stats4' needs to
be in "Depends" to ensure that it shadows the base functions it redefines.
Georgi Boshnakov
> coef
function (object, ...)
UseMethod("coef")
> library(stats4)
> coef
standardGeneric for "coef" defined from package "stats"
function (object, ...)
standardGeneric("coef")
Methods may be defined for arguments: object
Use showMethods("coef") for currently available ones.
===
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Georgi Boshnakov
Sent: 24 May 2018 15:38
To: joris.m...@ugent.be; R Package Development
Subject: Re: [R-pkg-devel] Creating S3 methods for S4 classes
My understanding is that the S3 methods guard against situations where only S3
dispatch is done,
e.g. by some internal generics. It may well be that for 'predict' this is not
theoretical possibility.
I second your suggestion about predict and stats4. I have wondered in the past
why 'predict' has been left out of stats4.
Georgi Boshnakov
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Joris Meys
Sent: 24 May 2018 13:17
To: R Package Development
Subject: [R-pkg-devel] Creating S3 methods for S4 classes
Dear all,
per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.
I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:
setGeneric("predict")
setMethod("predict", "ANY", stats::predict)
I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach
It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.
Any thoughts?
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Errors in my package
To Whom It May Concern:
I have created a package called "freeknotsplines" in R, and I need to
make a few updates to it. I resubmitted the package, and received the
following error message:
checking examples ... ERROR
Running examples in ‘freeknotsplines-Ex.R’ failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: coef.freekt
> ### Title: Compute Coefficients of B-Splines For Free-Knot Splines
> ### Aliases: coef.freekt
> ### Keywords: nonparametric regression smooth
>
> ### ** Examples
>
> x <- 0:30/30
> truey <- x*sin(10*x)
> set.seed(10556)
> y <- truey + rnorm(31, 0, 0.2)
> xy.freekt <- freelsgen(x, y, degree = 2, numknot = 2, 555)
> coef(xy.freekt)
Error: $ operator not defined for this S4 class
Execution halted
This error occurs in one of the examples in the documentation. It is
platform dependent, and does not occur on the machine I am using to create
the package. freekt is a new class, which is intended to be a S3 class,
not a S4 class.
Here is the code for coef.freekt:
coef.freekt <- function(object, ...)
{
xdat <- object@x
ydat <- object@y
optknot <- object@optknot
ord <- object@degree + 1
lambda <- object@lambda
fulloptknot <- c(rep(min(xdat), ord), optknot, rep(max(xdat), ord)) #
includes endpoints
Xmat <- splineDesign(fulloptknot, xdat, ord)
if ((lambda == 0) | (length(optknot) == 0))
coef <- solve(t(Xmat)%*%Xmat, t(Xmat)%*%ydat)
else
{
numknots <- length(optknot)
Amat <- chgbasismat(fulloptknot, ord)
Istar <- diag(c(rep(0, times = ord), rep(1, times = numknots)))
coef <- solve(t(Xmat)%*%Xmat + lambda*t(Amat)%*%Istar%*%Amat,
t(Xmat)%*%ydat)
}
return(coef)
}
Can someone please help me figure out what I am doing that is causing this
error?
Sincerely,
Steven Spiriti
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Errors in my package
Well, the computer is very good at doing what we ask it to, not what we intend
to.
In your case coef.freekt() clearly expects an S4 object (clue: object@) and
apparently that's what you feed it with.
A simple way to see where the problem actually comes from is
> options(error=recover)
> coef(xy.freekt)
Then explore what is going on.
Georgi Boshnakov
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Steven Spiriti
Sent: 24 May 2018 21:11
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Errors in my package
To Whom It May Concern:
I have created a package called "freeknotsplines" in R, and I need to
make a few updates to it. I resubmitted the package, and received the
following error message:
checking examples ... ERROR
Running examples in ‘freeknotsplines-Ex.R’ failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: coef.freekt
> ### Title: Compute Coefficients of B-Splines For Free-Knot Splines
> ### Aliases: coef.freekt
> ### Keywords: nonparametric regression smooth
>
> ### ** Examples
>
> x <- 0:30/30
> truey <- x*sin(10*x)
> set.seed(10556)
> y <- truey + rnorm(31, 0, 0.2)
> xy.freekt <- freelsgen(x, y, degree = 2, numknot = 2, 555)
> coef(xy.freekt)
Error: $ operator not defined for this S4 class
Execution halted
This error occurs in one of the examples in the documentation. It is
platform dependent, and does not occur on the machine I am using to create
the package. freekt is a new class, which is intended to be a S3 class,
not a S4 class.
Here is the code for coef.freekt:
coef.freekt <- function(object, ...)
{
xdat <- object@x
ydat <- object@y
optknot <- object@optknot
ord <- object@degree + 1
lambda <- object@lambda
fulloptknot <- c(rep(min(xdat), ord), optknot, rep(max(xdat), ord)) #
includes endpoints
Xmat <- splineDesign(fulloptknot, xdat, ord)
if ((lambda == 0) | (length(optknot) == 0))
coef <- solve(t(Xmat)%*%Xmat, t(Xmat)%*%ydat)
else
{
numknots <- length(optknot)
Amat <- chgbasismat(fulloptknot, ord)
Istar <- diag(c(rep(0, times = ord), rep(1, times = numknots)))
coef <- solve(t(Xmat)%*%Xmat + lambda*t(Amat)%*%Istar%*%Amat,
t(Xmat)%*%ydat)
}
return(coef)
}
Can someone please help me figure out what I am doing that is causing this
error?
Sincerely,
Steven Spiriti
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Errors in my package
On 24/05/2018 4:11 PM, Steven Spiriti wrote:
To Whom It May Concern:
I have created a package called "freeknotsplines" in R, and I need to
make a few updates to it. I resubmitted the package, and received the
following error message:
checking examples ... ERROR
Running examples in ‘freeknotsplines-Ex.R’ failed
The error most likely occurred in:
base::assign(".ptime", proc.time(), pos = "CheckExEnv")
### Name: coef.freekt
### Title: Compute Coefficients of B-Splines For Free-Knot Splines
### Aliases: coef.freekt
### Keywords: nonparametric regression smooth
### ** Examples
x <- 0:30/30
truey <- x*sin(10*x)
set.seed(10556)
y <- truey + rnorm(31, 0, 0.2)
xy.freekt <- freelsgen(x, y, degree = 2, numknot = 2, 555)
coef(xy.freekt)
Error: $ operator not defined for this S4 class
Execution halted
This error occurs in one of the examples in the documentation. It is
platform dependent, and does not occur on the machine I am using to create
the package. freekt is a new class, which is intended to be a S3 class,
not a S4 class.
But you are using the @ operator on it:
Here is the code for coef.freekt:
coef.freekt <- function(object, ...)
{
xdat <- object@x
ydat <- object@y
That's normally something that you would do with an S4 object. We can't
tell from your posting what xy.freekt really is; maybe it would help if
you posted the result of str(xy.freekt) after creating it.
Duncan Murdoch
optknot <- object@optknot
ord <- object@degree + 1
lambda <- object@lambda
fulloptknot <- c(rep(min(xdat), ord), optknot, rep(max(xdat), ord)) #
includes endpoints
Xmat <- splineDesign(fulloptknot, xdat, ord)
if ((lambda == 0) | (length(optknot) == 0))
coef <- solve(t(Xmat)%*%Xmat, t(Xmat)%*%ydat)
else
{
numknots <- length(optknot)
Amat <- chgbasismat(fulloptknot, ord)
Istar <- diag(c(rep(0, times = ord), rep(1, times = numknots)))
coef <- solve(t(Xmat)%*%Xmat + lambda*t(Amat)%*%Istar%*%Amat,
t(Xmat)%*%ydat)
}
return(coef)
}
Can someone please help me figure out what I am doing that is causing this
error?
Sincerely,
Steven Spiriti
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Courtesy methods and explosive dependencies
Package developers, I am trying to severely cut down on the number of dependencies of my package emmeans. It is now 48, which is quite a few (but that is down from over 100 in the preceding version, where I made the unwise choice of including a particularly greedy package in Imports). I hate to force users to install dozens of packages that they don't really need or want, but it seems very hard to avoid. Case in point: emmeans provides additional methods for 'cld' and 'glht' from the multcomp package. Accordingly, I import their generics, and register my additional methods. But because I import the generics, I must list multcomp in Imports, and that results in the addition of 16 required packages, some of which I never use. More important, I believe that NONE of those 16 packages are required for the correct functioning of my courtesy methods. The only things I really need are the generics. On the flip side, emmeans defines some generics of its own that I invite other package developers to extend so that emmeans supports their models. If those packages import emmeans, there is an overhead of 48 dependencies; again, most of these are packages that are not needed at all for those packages' methods to work. I don't like being responsible for that. I believe this is a very common problem, not just with my own packages. It's one thing to extend a base method like 'print'; but extending methods in contributed packages creates these dependency explosions. I have hundreds of packages installed on my system - a couple dozen I care about, another few dozen that seem fairly desirable, and a couple hundred that I don't even know what they're for, other than that things will break if I uninstall them. I do know of a couple ways to reduce these dependencies in the case of my multcomp dependencies: 1. I could simply export my S3 methods for cld and glht as functions, rather than registering them as S3 methods. Then I could move multcomp to Suggests. The downside is that it clutters the namespace for emmeans. 2. I could define the generics for cld and glht in my own package, and export them; and move multcomp to Suggests. Again, it clutters the namespace, and creates warning messages about (if not real issues with) masking. Probably (1) is better than (2), but is it better than what I do now? Is there something else that I (and probably a whole lot of other people) don't know? I wish there were an ImportGenerics or an ImportWithoutDependencies or some such field possible in DESCRIPTION. I appreciate any suggestions. Thanks Russ -- Russell V. Lenth - Professor Emeritus Department of Statistics and Actuarial Science The University of Iowa - Iowa City, IA 52242 USA Voice (319)335-0712 - FAX (319)335-3017 russell-le...@uiowa.edu - http://www.stat.uiowa.edu/~rlenth/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
