Re: [Rd] ... (dotMethods) and cbind/rbind: how to give the signature?
I find it easier to use S3 methods for cbind and rbind even for S4 classes. The
reason is that first you won't have different classes in the signature for
cbind/rbind and second is that ... signatures are only allowed if ALL arguments
are of the same class, whereas setGeneric("cbind") will force you to specify
deparse.level of a different class -- it does not work for me. If you however
try to redefine the cbind generic (as it is not generic initially) without
deparse.level you first face a compatibility problem and cbind for matrices
stops working.
If anybody has a working S4 solution I would be grateful for a hint:
setClass("ClassA", representation("matrix", comment="character"))
a = new("ClassA", matrix(runif(10),ncol=2), comment="aa")
b = new("ClassA", matrix(runif(15),ncol=3), comment="bb")
cbind.ClassA = mycbind = function(...) {
dots = list(...)
if (length(dots)<2) return(dots[[1]])
data = lapply(dots, function(x) x...@.data)
data = if (length(data)>1) do.call("cbind",data) else data[[1]]
comment = sapply(dots, function(x) x...@comment)
comment = paste(comment, collapse="; ")
new("ClassA", data, comment=comment)
}
cbind(a,b)
cbind(a...@.data, b...@.data)
With respect to your second question on S4 methods -- it gives room for
extendability and type checking, otherwise there is no good reason to define
functions as methods if you will only have one single implementation of
functionality with the same name.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Claudia Beleites
> Sent: 22 December 2008 14:27
> To: r-devel@r-project.org
> Subject: [Rd] ... (dotMethods) and cbind/rbind: how to give
> the signature?
>
> Dear List,
>
> I'm struggling with the signature writing cbind/rbind
> functions for a S4
> class.
>
> First of all, I'm very happy that it is now possible to
> dispatch on ...
> I follow the example for "paste" in ?dotMethods, which works
> as far as this:
>
> ### start example
> setClass ("cbtest",
> representation = representation (data = "data.frame"),
> prototype = prototype (data = data.frame (spc = I
> (matrix (rnorm
> (15) , 3, 5)))
> )
> )
>
> a <- new ("cbtest")
> a
>
> setMethod("cbind2", signature (x = "cbtest", y = "cbtest"),
> function (x, y){
> x...@data$spc <- cbind (x...@data$spc, y...@data$spc)
> x
> }
> )
>
>
> setMethod("cbind2", signature (x = "cbtest", y = "missing"),
> function (x, y)
> x)
>
> cb.cbind <- function (..., deparse.level){
> dots <- list (...)
> for (i in seq_along (dots)[-1])
> dots[[1]] <- cbind2 (dots[[1]], dots[[i]])
>
> dots[[1]]
> }
>
>
> cbind2 (a, a)
> cb.cbind (a, a, a)
>
>
> cbind (a, a, a)
> setGeneric ("cbind", signature = signature("..."))
> setMethod ("cbind", "cbtest",
>function (..., deparse.level) cb.cbind (...))
> cbind (a, a, a)
> cbind (a, a, a, deparse.level = 1)
>
> ### end example
>
>
> However, I get the following message:
> with setGeneric
>
> Creating a generic for "cbind" in package ".GlobalEnv"
> (the supplied definition differs from and overrides the
> implicit generic in
> package "base": Signatures differ: (...), (deparse.level))
>
> How do I specify the correct signature?
>
> Furthermore: as I do not want to do anything with
> "deparse.level", I'd rather
> specify it as "missing" in setMethod. But again, I don't get
> the signature
> correct.
>
> I tried
> setGeneric ("cbind", signature = signature (...="...",
> deparse.level =
> "integer"))
> and
> setGeneric ("cbind", signature = signature ("...",
> deparse.level = "integer"))
>
> both give:
> Fehler in makeGeneric(name, fdef, fdeflt, group = group, valueClass =
> valueClass, :
> Nicht-Argumente in der Signatur: integer
>
> What is my mistake?
>
> Thanks a lot for your help!
>
> Claudia
>
>
> > version
>_
> platform i486-pc-linux-gnu
> arch i486
> os linux-gnu
> system i486, linux-gnu
> status
> major 2
> minor 8.0
> year 2008
> month 10
> day20
> svn rev46754
> language R
> version.string R version 2.8.0 (2008-10-20)
>
>
> --
> Claudia Beleites
> Dipartimento dei Materiali e delle Risorse Naturali
> Università degli Studi di Trieste
> Via Alfonso Valerio 6/a
> I-34127 Trieste
>
> phone: +39 (0 40) 5 58-34 47
> email: cbelei...@un
Re: [Rd] rscproxy version conflict
Simon Urbanek wrote:
> FWIW: technically, you don't have to match the patch level version.
> Although default DLL checks usually require perfect match, it should
> be safe to require that R version lies in [x.y.z, x.y+1.0) where
> x.y.z is the R version that the interfacing DLL was compiled against.
> (And hence it is safe to use R x.y.0 as the base for compilation until
> R x.y+1.0 is released).
The check that has been implemented works as:
snprintf(Rversion, 25, "%s.%s", R_MAJOR, R_MINOR);
if(strncmp(getDLLVersion(), Rversion, 25) != 0) {
... check failed
}
... check ok
Quoting from http://cran.r-project.org/doc/manuals/R-exts.html
int main (int argc, char **argv)
{
structRstart rp;
Rstart Rp = &rp;
char Rversion[25], *RHome;
sprintf(Rversion, "%s.%s", R_MAJOR, R_MINOR);
if(strcmp(getDLLVersion(), Rversion) != 0) {
fprintf(stderr, "Error: R.DLL version does not match\n");
exit(1);
}
...
this looks very similar. According to your message, full binary
compatibility is given for same R (major.minor) versions, e.g. 2.8.0 is
fully compatible with 2.8.1, but may not be fully compatible with 2.9.0.
Is there a "compatible DLL version" that can be queried or is using
getDLLVersion() the recommended approach and ignoring everything after the
second '.'?
And if 2.8.0 and 2.8.1 are fully compatible, why is a warning issued, if a
package built with R 2.8.1 is loaded in R 2.8.0?
Thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
On Tue, 23 Dec 2008, Thomas Baier wrote:
Simon Urbanek wrote:
FWIW: technically, you don't have to match the patch level version.
Although default DLL checks usually require perfect match, it should
be safe to require that R version lies in [x.y.z, x.y+1.0) where
x.y.z is the R version that the interfacing DLL was compiled against.
(And hence it is safe to use R x.y.0 as the base for compilation until
R x.y+1.0 is released).
The check that has been implemented works as:
snprintf(Rversion, 25, "%s.%s", R_MAJOR, R_MINOR);
if(strncmp(getDLLVersion(), Rversion, 25) != 0) {
... check failed
}
... check ok
Quoting from http://cran.r-project.org/doc/manuals/R-exts.html
int main (int argc, char **argv)
{
structRstart rp;
Rstart Rp = &rp;
char Rversion[25], *RHome;
sprintf(Rversion, "%s.%s", R_MAJOR, R_MINOR);
if(strcmp(getDLLVersion(), Rversion) != 0) {
fprintf(stderr, "Error: R.DLL version does not match\n");
exit(1);
}
...
this looks very similar. According to your message, full binary
compatibility is given for same R (major.minor) versions, e.g. 2.8.0 is
fully compatible with 2.8.1, but may not be fully compatible with 2.9.0.
Is there a "compatible DLL version" that can be queried or is using
getDLLVersion() the recommended approach and ignoring everything after the
second '.'?
The latter. It is expected that the C-level API is compatible
throughout 2.8.x, but people do use non-API entry points, hence the more
rigid check in this example.
And if 2.8.0 and 2.8.1 are fully compatible, why is a warning issued, if a
package built with R 2.8.1 is loaded in R 2.8.0?
They may not be compatible at R function level: new features are allowed,
as well as bug fixes which code may rely on.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Align legend title wish remainder (PR#13415)
Full_Name: Gregor Gorjanc Version: 2.8.0 and above OS: generic Submission from: (NULL) (82.192.44.219) This is just a remainder for a wish to align legend title as reported and "solved" at https://stat.ethz.ch/pipermail/r-devel/2008-December/051642.html Thanks! Regards, Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
On Dec 23, 2008, at 11:29 AM, Thomas Baier wrote:
Simon Urbanek wrote:
FWIW: technically, you don't have to match the patch level version.
Although default DLL checks usually require perfect match, it should
be safe to require that R version lies in [x.y.z, x.y+1.0) where
x.y.z is the R version that the interfacing DLL was compiled against.
(And hence it is safe to use R x.y.0 as the base for compilation
until
R x.y+1.0 is released).
The check that has been implemented works as:
snprintf(Rversion, 25, "%s.%s", R_MAJOR, R_MINOR);
if(strncmp(getDLLVersion(), Rversion, 25) != 0) {
... check failed
}
... check ok
Quoting from http://cran.r-project.org/doc/manuals/R-exts.html
int main (int argc, char **argv)
{
structRstart rp;
Rstart Rp = &rp;
char Rversion[25], *RHome;
sprintf(Rversion, "%s.%s", R_MAJOR, R_MINOR);
if(strcmp(getDLLVersion(), Rversion) != 0) {
fprintf(stderr, "Error: R.DLL version does not match\n");
exit(1);
}
...
this looks very similar. According to your message, full binary
compatibility is given for same R (major.minor) versions, e.g. 2.8.0
is
fully compatible with 2.8.1, but may not be fully compatible with
2.9.0.
Is there a "compatible DLL version" that can be queried or is using
getDLLVersion() the recommended approach and ignoring everything
after the
second '.'?
And if 2.8.0 and 2.8.1 are fully compatible, why is a warning
issued, if a
package built with R 2.8.1 is loaded in R 2.8.0?
It's ok to use a package built for 2.8.0 in 2.8.1 but not vice versa.
It is rare, but it has happened before that a bugfix or visibility
change adds a symbol in x.y.1 that was not there in x.y.0. Then if
your package checks for that particular feature and uses it you cannot
use that binary with x.y.0. Again, this is rather rare and you as the
package author know about it, but to be on the safe side I was
recommending against that. However, as Brian pointed out this happens
far more often on the R function level than on the C API level.
(I know about this DLL version check because it was the first change I
made to JRI since I wasn't willing to release Windows binary some five
times a year ;)).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
