Re: [R-pkg-devel] UseR! Session: Navigating the jungle of R packages
As a way to organize discussion for the session AND for the hopefully derivative development, I have set up a Github project https://github.com/nashjc/Rnavpkg In particular, I've started a small wiki therein, and especially have built a page "Ideas and people" where I have tried to summarize succinctly the comments so far. I'm absolutely sure I've missed some contributions and got some ideas bent, and ask your indulgence and assistance. I'll be happy to give access to edit/improve things (and freely admit the Github process is a bit new to me, being used to svn on R-forge). Julia has suggested rmdshower for preparing slide presentations (which clearly can be collaboratively developed on Rnavpkg). I also note that one can use RStudio File/New/File/Presentation, though I haven't checked how these render to other than html. Cheers, John Nash __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Is a double dispatch possible with two S3 classes?
Hello,
I have stumbled upon an S3 class dispatch issue which is easily solved
using S4 classes, but I'd like to know if there is a way to solve it
without changing the type of class used.
The problem is as follows. There is an S3 class 'foo' which is defined
in a package over which I don't have control. Then there is an S3 class
'bar' derived from 'foo' in a package that can be modified.
Here is some code for 'foo':
as.foo <- function(x) {
oldClass(x) <- "foo"
x
}
print.foo <- function(x, ...) print(paste(x, "foo"))
"-.foo" <- function(e1, e2) "-.foo was called"
And here is some code for 'bar':
as.bar <- function(x) {
oldClass(x) <- c("bar", "foo")
x
}
print.bar <- function(x, ...) print(paste(x, "bar"))
Now the '-' operator must be defined in such a way that the behaviour is
different depending on the operand classes, and in particular
'bar'-'bar' needs to be different from 'bar'-'foo'. If I define the
following function:
"-.bar" <- function(e1, e2) "-.bar was called"
then I get the following results.
as.foo(1) - as.foo(2) # uses '-.foo'
as.bar(1) - as.bar(2) # uses '-.bar'
as.bar(1) - as.foo(2) # uses '-.default' and issues
# Incompatible methods warning
as.foo(1) - as.bar(2) # uses '-.default' and issues
# Incompatible methods warning
So that seems like a dead end.
If, overcoming an instinctive shudder of disgust, I redefine '-.foo' in
the "bar" package, I have checked that correctness is at the mercy of
the order of loading of the packages, even though the "bar" package
imports the "foo" package. So that doesn't seem to work either.
Before committing to making 'bar' an S4 class, does anyone know if there
is another option that would allow 'bar' to remain an S3 class?
Thanks,
Leo
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is a double dispatch possible with two S3 classes?
On 16/02/2017 11:52 AM, Leonardo Silvestri wrote:
Hello,
I have stumbled upon an S3 class dispatch issue which is easily solved
using S4 classes, but I'd like to know if there is a way to solve it
without changing the type of class used.
The problem is as follows. There is an S3 class 'foo' which is defined
in a package over which I don't have control. Then there is an S3 class
'bar' derived from 'foo' in a package that can be modified.
Here is some code for 'foo':
as.foo <- function(x) {
oldClass(x) <- "foo"
x
}
print.foo <- function(x, ...) print(paste(x, "foo"))
"-.foo" <- function(e1, e2) "-.foo was called"
And here is some code for 'bar':
as.bar <- function(x) {
oldClass(x) <- c("bar", "foo")
x
}
print.bar <- function(x, ...) print(paste(x, "bar"))
Now the '-' operator must be defined in such a way that the behaviour is
different depending on the operand classes, and in particular
'bar'-'bar' needs to be different from 'bar'-'foo'. If I define the
following function:
"-.bar" <- function(e1, e2) "-.bar was called"
then I get the following results.
as.foo(1) - as.foo(2) # uses '-.foo'
as.bar(1) - as.bar(2) # uses '-.bar'
as.bar(1) - as.foo(2) # uses '-.default' and issues
# Incompatible methods warning
as.foo(1) - as.bar(2) # uses '-.default' and issues
# Incompatible methods warning
So that seems like a dead end.
If, overcoming an instinctive shudder of disgust, I redefine '-.foo' in
the "bar" package, I have checked that correctness is at the mercy of
the order of loading of the packages, even though the "bar" package
imports the "foo" package. So that doesn't seem to work either.
Before committing to making 'bar' an S4 class, does anyone know if there
is another option that would allow 'bar' to remain an S3 class?
I don't think so, though you could conceivably check whether things will
work when bar is loaded, and fail with a message saying "bar must be
loaded first!" or whatever.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] registering native routines and references as R objects
I am working on an update to my package pcaL1. Using win-builder, I
get a note including "Found no calls to 'R_registerRoutines',
'R_useDynamicSymbols'". However, in my submission, I have a file
src/init.c that includes the contents at the bottom of this email to
register .C() routines. Why can't win-builder find the calls to these
functions?
Also, when I include "useDynLib(pcaL1, .registration=TRUE,
.fixes="C_")" in NAMESPACE so that I can refer to the routines as R
objects, I get a warning that the objects C_* are not documented. Is
it okay to ignore this warning? It appears that the package stats
does not document such objects.
The contents of src/init.c:
#include "type.h"
#include
#include
#include
void l1pcahp (double *points_XT, int *dataDim, double *threshold,
double *initV, double *PCs);
void l1pcastar (double *points_XT, int *dataDim, int *q, double *PCs);
void l1pca (double *points_XT, int *dataDim, int *q, double
*tolerance, int *iterations, double *initV, double *PCs, double
*Scores);
void l1projection (double *points_XT, int *dataDim, int *q, double
*PCs, double *projPoints, double *alphas);
void pcal1 (double *points_XT, int *dataDim, int *q, double *PCs, int
*initMethod, double *initV);
void pcalp (double *points_XT, int *dataDim, int *q, double *p, double
*PCs, int *initMethod, int *solMethod, double *initV, double *epsilon,
double *lratio);
void sharpel1pca (double *points_XT, int *dataDim, int *q, double
*PCs, double *objectives);
#define C_DEF(name, n) {#name, (DL_FUNC) &name, n}
static const R_CMethodDef cMethods[] = {
C_DEF(l1pcahp, 5),
C_DEF(l1pcastar, 4),
C_DEF(l1pca, 8),
C_DEF(l1projection, 6),
C_DEF(pcal1, 6),
C_DEF(pcalp, 10),
C_DEF(sharpel1pca, 5),
{NULL, NULL, 0}
};
void attribute_visible R_init_pcaL1(DllInfo *info)
{
R_registerRoutines(info, cMethods, NULL, NULL, NULL);
R_useDynamicSymbols(info, FALSE);
R_forceSymbols(info, TRUE);
}
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
