Re: [Rd] trivial spelling correction
> "SO" == Sean O'Riordain <[EMAIL PROTECTED]>
> on Mon, 1 Dec 2008 19:32:13 + writes:
SO> Good evening,
SO> Spotted a very minor spelling mistake in the source for the grep help.
SO> And thanks to R-Core for all their work - it's a tribute to R-Core,
SO> that these sort of "problems" are rare indeed.
Thank you, Sean, that's fixed now.
Martin
SO> Best regards,
SO> Sean O'Riordain
SO> Dublin
SO> [EMAIL PROTECTED]:~/R/RSVN/R/trunk/src/library/base/man$ svn diff
SO> Index: grep.Rd
SO> ===
SO> --- grep.Rd (revision 47031)
SO> +++ grep.Rd (working copy)
SO> @@ -102,7 +102,7 @@
SO> For \code{sub} and \code{gsub} a character vector of the same length
SO> and with the same attributes as \code{x} (after possible coercion).
SO> - Elements of character vectors \code{x} which are not subsituted will
SO> + Elements of character vectors \code{x} which are not substituted will
SO> be return unchanged (including any declared encoding). If
SO> \code{useBytes = FALSE}, either \code{perl = TRUE} or \code{fixed =
SO> TRUE} and any element of \code{pattern}, \code{replacement} and
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nlminb: names of parameter vector not passed to objective function
Dear R developers,
I tried to use nlminb instead of optim for a current problem (fitting
parameters of a differential equation model). The PORT algorithm
converged much better than any of optim's methods and the identified
parameters are plausible. However, it took me a while before spotting
the reason of a technical problem that nlminb, in contrast to optim,
does not pass names of the start parameters to the objective function.
Please find below a minimum reproducible example. There is, of course, a
workaround, but in order to make optim and nlme more compatible I would
ask whether it would be possible to change this idiosyncratic behavior?
Tested with:
R version 2.8.0 Patched (2008-11-04 r46830) i386-pc-mingw32
and also
R version 2.9.0 Under development (unstable) (2008-12-03 r47039)
i386-pc-mingw32
Thanks a lot
Thomas Petzoldt
set.seed(3577) # make it reproducible
## 1) example taken from ?nlminb -
x <- rnbinom(100, mu = 10, size = 10)
hdev <- function(par) {
-sum(dnbinom(x, mu = par[1], size = par[2], log = TRUE))
}
nlminb(c(20, 20), hdev, lower = 0.001, upper = Inf)
## --> works without problems
## 2) same example, but with named vectors -
hdev <- function(par) {
cat(names(par), "\n") # show what happens
-sum(dnbinom(x, mu = par["mu"], size = par["size"], log = TRUE))
}
start <- c(mu=20, size=20)
optim(start, hdev, lower = 0.001, upper = Inf, method="L-BFGS-B")
## --> works without problems
## 3) THE PROBLEM
nlminb(start, hdev, lower = 0.001, upper = Inf)
## --> $objective is NA because names of "start" are not passed through
## 4) workaround ---
hdev <- function(par, pnames) {
names(par) <- pnames
-sum(dnbinom(x, mu = par["mu"], size = par["size"], log = TRUE))
}
nlminb(start, hdev, pnames = names(start), lower = 0.001, upper = Inf)
## --> works, but is it possible to improve nlminb
## so that the workaround can be avoided ?
--
Thomas Petzoldt
Technische Universitaet Dresden
Institut fuer Hydrobiologie[EMAIL PROTECTED]
01062 Dresden http://tu-dresden.de/hydrobiologie/
GERMANY
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nlminb: names of parameter vector not passed to objective function
On Wed, 3 Dec 2008, Thomas Petzoldt wrote:
Dear R developers,
I tried to use nlminb instead of optim for a current problem (fitting
parameters of a differential equation model). The PORT algorithm converged
much better than any of optim's methods and the identified parameters are
plausible. However, it took me a while before spotting the reason of a
technical problem that nlminb, in contrast to optim, does not pass names of
the start parameters to the objective function.
Please find below a minimum reproducible example. There is, of course, a
workaround, but in order to make optim and nlme more compatible I would ask
whether it would be possible to change this idiosyncratic behavior?
The 'idiosyncratic behavior' is to expect that a new vector of parameters
will magically inherit names from the start vector. optim() was changed
(and documented) because some users asked for this, and if a user who
wants it for nlminb provides a tested patch, I am sure it will be
considered.
Note the documentation difference.
Tested with:
R version 2.8.0 Patched (2008-11-04 r46830) i386-pc-mingw32
and also
R version 2.9.0 Under development (unstable) (2008-12-03 r47039)
i386-pc-mingw32
Thanks a lot
Thomas Petzoldt
set.seed(3577) # make it reproducible
## 1) example taken from ?nlminb -
x <- rnbinom(100, mu = 10, size = 10)
hdev <- function(par) {
-sum(dnbinom(x, mu = par[1], size = par[2], log = TRUE))
}
nlminb(c(20, 20), hdev, lower = 0.001, upper = Inf)
## --> works without problems
## 2) same example, but with named vectors -
hdev <- function(par) {
cat(names(par), "\n") # show what happens
-sum(dnbinom(x, mu = par["mu"], size = par["size"], log = TRUE))
}
start <- c(mu=20, size=20)
optim(start, hdev, lower = 0.001, upper = Inf, method="L-BFGS-B")
## --> works without problems
## 3) THE PROBLEM
nlminb(start, hdev, lower = 0.001, upper = Inf)
## --> $objective is NA because names of "start" are not passed through
## 4) workaround ---
hdev <- function(par, pnames) {
names(par) <- pnames
-sum(dnbinom(x, mu = par["mu"], size = par["size"], log = TRUE))
}
nlminb(start, hdev, pnames = names(start), lower = 0.001, upper = Inf)
## --> works, but is it possible to improve nlminb
## so that the workaround can be avoided ?
--
Thomas Petzoldt
Technische Universitaet Dresden
Institut fuer Hydrobiologie[EMAIL PROTECTED]
01062 Dresden http://tu-dresden.de/hydrobiologie/
GERMANY
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
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
Re: [Rd] nlminb: names of parameter vector not passed to objective function
Dear Prof. Ripley,
thank you very much for the fast response. I am very grateful for all
the work that the R Core does and so I try to contribute my humble part
as a tester.
Prof Brian Ripley wrote:
On Wed, 3 Dec 2008, Thomas Petzoldt wrote:
Dear R developers,
I tried to use nlminb instead of optim for a current problem (fitting
parameters of a differential equation model). The PORT algorithm
converged much better than any of optim's methods and the identified
parameters are plausible. However, it took me a while before spotting
the reason of a technical problem that nlminb, in contrast to optim,
does not pass names of the start parameters to the objective function.
Please find below a minimum reproducible example. There is, of course,
a workaround, but in order to make optim and nlme more compatible I
would ask whether it would be possible to change this idiosyncratic
behavior?
The 'idiosyncratic behavior' is to expect that a new vector of
parameters will magically inherit names from the start vector. optim()
was changed (and documented) because some users asked for this, and if a
user who wants it for nlminb provides a tested patch, I am sure it will
be considered.
O.K., than I will make my, surely naive, suggestion to change file:
src/library/stats/R/nlminb.R
As far I can oversee it, names are dropped at the beginning in:
## Establish the working vectors and check and set options
n <- length(par <- as.double(start))
so it may be sufficient to add something like:
names(par) <- names(start)
anywhere before:
assign(".par", par, envir = rho)
This change was sufficient to make my example working and (at a first
look) I did not find negative side-effects. At least:
R CMD check stats
passed without problems. I had also a look into port.c and found nothing
obvious there so I, again naively, assume that there is (hopefully)
nothing to do at the C level. It would be very kind if someone more
experienced can validate (or falsify) this.
Thank you very much
Thomas Petzoldt
Index: nlminb.R
===
--- nlminb.R(revision 47039)
+++ nlminb.R(working copy)
@@ -48,6 +48,7 @@
## Establish the objective function and its environment
obj <- quote(objective(.par, ...))
rho <- new.env(parent = environment())
+names(par) <- names(start)
assign(".par", par, envir = rho)
## Create values of other arguments if needed
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] syntax error in platform.c (PR#13354)
Full_Name: Anne Bracy Version: 2.8.0 OS: linux Submission from: (NULL) (192.55.52.12) syntax error in platform.c line 1657, missing ";" after the word FALSE __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A small bug in R code of the legend function of the Graphics (PR#13350)
Martin Maechler wrote:
> but do.lines is never specified. It can be FALSE (if there are no
> lines drawn) and a user can indeed set 'merge = TRUE" in such a
> situation.
> However, can you think of a situation where this was desirable?
> I think it should not have any effect in such a case
> {... but unfortunately it currently has ... yet another
> sign that legend() is ``hopelessly over-featured'' ;-) }
> and possibly rather give a warning in such a case...
>
>
> ASh> Guess that seg.len should be initialized before the condition "if
> (do.lines)"
>
> not really; it means 'segment length' should not be used unless
> segments ("lines") are drawn.
>
> Thank you for your note; you are right that legend() is not
> entirely correct in such a border-line situation.
>
> Regards,
> Martin Maechler, ETH Zurich
Thanks for the response.
Yes it's unusual to set merge without lines. I modified existing code and
didn't pay attention
to the merge parameter and got the error "object "seg.len" not found". There
was no connection
between the merge parameter and the error produced. So I modified the code and
didn't unset
merge :). So it's better to gave an warning, or to set automatically merge to
false if isn't needed.
Arkady
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Matrix dimnames crash (PR#13361)
In Windows XP, the matrix() function crashes the program when 'dimnames' is an empty list: matrix(1:4, nrow=2, dimnames=list()) # R has encountered a problem and needs to close ... This bug is specific to WinXP, as Linux64 handles this situation more gracefully: matrix(1:4, nrow=2, dimnames=list()) Error in matrix(1:4, nrow = 2, dimnames = list()) : invalid type (environment) for 'dimnames' (must be a vector) Thanks, Arni R 2.8.0-patched on WinXP __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error code query (PR#13360)
Hi I'm working on installing R and Rcmdr on a Mac running Leopard. I've had it running in the past and had to reinstall 11X iwhen putting some notes together for students. To get screen shots I reinstalled 11X without unstalling it first. Having loaded the additional packages with Rcmdr, when I try to open Rcmdr I now get the following error messages: Error: .onload failed in 'loadNamespace' for 'Rcmdr' Error: package/namespace load failed for Rcmdr'' _X11TransSocketINTETConnect() can't get address for /tmp/launch- vCmK4L/:6000: nodename nor servname provided, or not know The last line X11 etc appears in red text. Any suggestion help would be grateful. Cheers, Alan. Alan Wylie Educational Developer Faculty of Arts and Sciences University of New England Armidale NSW 2351 Phone: 02 6773 2988 Mobile: 0403 335 964 email: [EMAIL PROTECTED] Room 384 Mcclymont building CRICOS Provider Number 3G [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] syntax error in platform.c (PR#13354)
This was corrected way back in October. Please do read the FAQ and not report already fixed issues. On Mon, 1 Dec 2008, [EMAIL PROTECTED] wrote: Full_Name: Anne Bracy Version: 2.8.0 OS: linux Submission from: (NULL) (192.55.52.12) syntax error in platform.c line 1657, missing ";" after the word FALSE __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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
Re: [Rd] Matrix dimnames crash (PR#13361)
On Wed, 3 Dec 2008, [EMAIL PROTECTED] wrote: In Windows XP, the matrix() function crashes the program when 'dimnames' is an empty list: matrix(1:4, nrow=2, dimnames=list()) # R has encountered a problem and needs to close ... This bug is specific to WinXP, as Linux64 handles this situation more gracefully: matrix(1:4, nrow=2, dimnames=list()) Error in matrix(1:4, nrow = 2, dimnames = list()) : invalid type (environment) for 'dimnames' (must be a vector) Actually no (the reported type is wrong, and my x86_64 Linux system also crashes). This case slips though the error-checking, and I've added a final error check that will catch it in R-patched. Thank you for the report. Thanks, Arni R 2.8.0-patched on WinXP __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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
Re: [Rd] Matrix dimnames crash (PR#13361)
Brian,
Your change to src/main/attrib.c:dimnamesgets(),
--- attrib.c(revision 47045)
+++ attrib.c(working copy)
@@ -857,6 +857,9 @@
UNPROTECT(1);
PROTECT(val = newval);
}
+if (k != length(val))
+ error(_("length of 'dimnames' [%d] must match that of 'dims'
[%d]"),
+ length(val), k);
for (i = 0; i < k; i++) {
SEXP _this = VECTOR_ELT(val, i);
if (_this != R_NilValue) {
results in array() and matrix() treating dimnames=list() differently
and I think they ought to act the same when feasible.
Also, the error message is not really the right one, as the length
of the dimnames handed to the array() or matrix() function does not
have to be the length of dim - a short one gets padded with NULL's.
(I don't know if this padding is the best thing to do -- R does it
and S+ does not -- and I think it generally reflects user error.)
E.g., in R:
> f<-function(dimnames){
mat<-try(matrix(1:6,nrow=2,dimnames=dimnames), silent=TRUE)
arr<-try(array(1:6,dim=c(2,3),dimnames=dimnames), silent=TRUE)
list(matrix=mat, array=arr, identical=identical(mat, arr))
}
> f(dimnames=NULL)
$matrix
[,1] [,2] [,3]
[1,]135
[2,]246
$array
[,1] [,2] [,3]
[1,]135
[2,]246
$identical
[1] TRUE
> f(dimnames=list())
$matrix
[1] "Error in matrix(1:6, nrow = 2, dimnames = dimnames) : \n length of
'dimnames' [0] must match that of 'dims' [2]\n"
attr(,"class")
[1] "try-error"
$array
[,1] [,2] [,3]
[1,]135
[2,]246
$identical
[1] FALSE
> f(dimnames=list(Row=LETTERS[24:25])) # short dimnames
$matrix
Row [,1] [,2] [,3]
X135
Y246
$array
Row [,1] [,2] [,3]
X135
Y246
$identical
[1] TRUE
The following change to src/main/array.c makes array() and matrix()
treat dimnames=list() in the same way (equivalent to dimnames=NULL.
--- array.c (revision 47047)
+++ array.c (working copy)
@@ -152,7 +152,7 @@
;
}
}
-if(!isNull(dimnames)) ans = dimnamesgets(ans, dimnames);
+if(!isNull(dimnames) && length(dimnames)>0) ans = dimnamesgets(ans,
dimnames);
UNPROTECT(1);
return ans;
}
The change to attrib.c:dimnamesgets() is fine: this change to
array.c:do_matrix just avoids the call.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian Ripley
> Sent: Wednesday, December 03, 2008 9:14 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Rd] Matrix dimnames crash (PR#13361)
>
> On Wed, 3 Dec 2008, [EMAIL PROTECTED] wrote:
>
> > In Windows XP, the matrix() function crashes the program
> when 'dimnames'
> > is an empty list:
> >
> > matrix(1:4, nrow=2, dimnames=list())
> > # R has encountered a problem and needs to close ...
> >
> > This bug is specific to WinXP, as Linux64 handles this
> situation more
> > gracefully:
> >
> > matrix(1:4, nrow=2, dimnames=list())
> > Error in matrix(1:4, nrow = 2, dimnames = list()) :
> > invalid type (environment) for 'dimnames' (must be a vector)
>
> Actually no (the reported type is wrong, and my x86_64 Linux
> system also
> crashes).
>
> This case slips though the error-checking, and I've added a
> final error
> check that will catch it in R-patched.
>
> Thank you for the report.
>
> >
> > Thanks,
> > Arni
> >
> > R 2.8.0-patched on WinXP
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix dimnames crash (PR#13361)
On Wed, 3 Dec 2008, William Dunlap wrote:
Brian,
Your change to src/main/attrib.c:dimnamesgets(),
--- attrib.c(revision 47045)
+++ attrib.c(working copy)
@@ -857,6 +857,9 @@
UNPROTECT(1);
PROTECT(val = newval);
}
+if (k != length(val))
+ error(_("length of 'dimnames' [%d] must match that of 'dims'
[%d]"),
+ length(val), k);
for (i = 0; i < k; i++) {
SEXP _this = VECTOR_ELT(val, i);
if (_this != R_NilValue) {
results in array() and matrix() treating dimnames=list() differently
and I think they ought to act the same when feasible.
Also, the error message is not really the right one, as the length
of the dimnames handed to the array() or matrix() function does not
have to be the length of dim - a short one gets padded with NULL's.
(I don't know if this padding is the best thing to do -- R does it
and S+ does not -- and I think it generally reflects user error.)
Not always: setting dimnames(A)[[1]] is the crux example.
E.g., in R:
f<-function(dimnames){
mat<-try(matrix(1:6,nrow=2,dimnames=dimnames), silent=TRUE)
arr<-try(array(1:6,dim=c(2,3),dimnames=dimnames), silent=TRUE)
list(matrix=mat, array=arr, identical=identical(mat, arr))
}
f(dimnames=NULL)
$matrix
[,1] [,2] [,3]
[1,]135
[2,]246
$array
[,1] [,2] [,3]
[1,]135
[2,]246
$identical
[1] TRUE
f(dimnames=list())
$matrix
[1] "Error in matrix(1:6, nrow = 2, dimnames = dimnames) : \n length of
'dimnames' [0] must match that of 'dims' [2]\n"
attr(,"class")
[1] "try-error"
$array
[,1] [,2] [,3]
[1,]135
[2,]246
$identical
[1] FALSE
f(dimnames=list(Row=LETTERS[24:25])) # short dimnames
$matrix
Row [,1] [,2] [,3]
X135
Y246
$array
Row [,1] [,2] [,3]
X135
Y246
$identical
[1] TRUE
The following change to src/main/array.c makes array() and matrix()
treat dimnames=list() in the same way (equivalent to dimnames=NULL.
which is not obvious to me is correct.
--- array.c (revision 47047)
+++ array.c (working copy)
@@ -152,7 +152,7 @@
;
}
}
-if(!isNull(dimnames)) ans = dimnamesgets(ans, dimnames);
+if(!isNull(dimnames) && length(dimnames)>0) ans = dimnamesgets(ans,
dimnames);
UNPROTECT(1);
return ans;
}
The change to attrib.c:dimnamesgets() is fine: this change to
array.c:do_matrix just avoids the call.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian Ripley
Sent: Wednesday, December 03, 2008 9:14 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Rd] Matrix dimnames crash (PR#13361)
On Wed, 3 Dec 2008, [EMAIL PROTECTED] wrote:
In Windows XP, the matrix() function crashes the program
when 'dimnames'
is an empty list:
matrix(1:4, nrow=2, dimnames=list())
# R has encountered a problem and needs to close ...
This bug is specific to WinXP, as Linux64 handles this
situation more
gracefully:
matrix(1:4, nrow=2, dimnames=list())
Error in matrix(1:4, nrow = 2, dimnames = list()) :
invalid type (environment) for 'dimnames' (must be a vector)
Actually no (the reported type is wrong, and my x86_64 Linux
system also
crashes).
This case slips though the error-checking, and I've added a
final error
check that will catch it in R-patched.
Thank you for the report.
Thanks,
Arni
R 2.8.0-patched on WinXP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
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
--
Brian D. Ripley, [EMAIL PROTECTED]
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] reduce limit number of arguments in methods:::cbind
Dear all,
As far as I understand, the number of arguments in methods:::cbind is
limited by the "self recursive" construction of the function
which generates nested loops.
A workaround could be to use the internal cbind function on blocks of
non S4 objects. The limitation would then be reduced to the number of
consecutive S4 objects.
# R code #
dfr <- data.frame(matrix(0, nrow = 1 , ncol = 1000))
dfr2 <- is.na(dfr)
mlist <- rep(list(matrix(0, 2, 1)), 400)
cb1 <- do.call("cbind", c(mlist, mlist))
methods:::bind_activation(TRUE)
dfr2 <- is.na(dfr) # fails
cb2 <- do.call("cbind", mlist) # ok
cb3 <- do.call("cbind", c(mlist, mlist)) # fails
# This could be avoided by first checking that the arguments has no S4
# objects. If this is the case, the function falls back to the
# internal cbind function.
# But this would not be very helpful if the arguments are a mixture of
# S4 and non S4 objects
library(Matrix)
Mlist <- rep(list(Matrix(0, 2, 1)), 400)
cb4 <- do.call("cbind", Mlist) # ok
cb5 <- do.call("cbind", c(Mlist, Mlist)) # fails
cb6 <- do.call("cbind", c(Mlist, mlist)) # fails
# A workaround could be to use the internal cbind function on blocks of
# non S4 objects. The limitation would be reduced to the number of
# consecutive S4 objects
# After modifications
dfr2 <- is.na(dfr) # ok
cb7 <- do.call("cbind", mlist) # ok
cb8 <- do.call("cbind", c(mlist, mlist)) # ok
cb9 <- do.call("cbind", c(Mlist, mlist)) # ok
cb10 <- do.call("cbind", c(Mlist, Mlist)) # fails as expected
# END #
The code bellow gives an idea how to do it but was not fully tested!
Hope it helps,
Yohan
Index: methods/R/cbind.R
===
--- methods/R/cbind.R (revision 47045)
+++ methods/R/cbind.R (working copy)
@@ -39,11 +39,10 @@
## remove trailing 'NULL's:
while(na > 0 && is.null(argl[[na]])) { argl <- argl[-na]; na <- na - 1 }
if(na == 0) return(NULL)
-if(na == 1) {
- if(isS4(..1))
- return(cbind2(..1))
- else return(.Internal(cbind(deparse.level, ...)))
-}
+if (!any(aS4 <- unlist(lapply(argl, isS4
+return(.Internal(cbind(deparse.level, ...)))
+if(na == 1)
+return(cbind2(..1))
## else : na >= 2
@@ -64,6 +63,15 @@
else { ## na >= 3 arguments: -- RECURSION -- with care
## determine nrow() for e.g., cbind(diag(2), 1, 2)
## only when the last two argument have *no* dim attribute:
+idx.aS4 <- 0
+while (!rev(aS4)[idx.aS4+1])
+idx.aS4 <- idx.aS4 + 1
+if (idx.aS4 > 1) {
+argl0 <- argl[(na-idx.aS4+1):na]
+argl1 <- do.call(cbind, c(argl0,
list(deparse.level=deparse.level)))
+argl2 <- c(argl[1L:(na-idx.aS4)], list(argl1))
+return(do.call(cbind, c(argl2, list(deparse.level=deparse.level
+}
nrs <- unname(lapply(argl, nrow)) # of length na
iV <- sapply(nrs, is.null)# is 'vector'
fix.na <- identical(nrs[(na-1):na], list(NULL,NULL))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reduce limit number of arguments in methods:::cbind
My 2c: The real issue for me is that this approach to handling S4 objects by altering R functions for the worse is incorrect. (by calling bind_activation) m <- matrix(1:2e6L) # 2 million obs > system.time(cbind(m,m)) user system elapsed 0.027 0.017 0.044 > methods:::bind_activation(TRUE) [1] FALSE # the additional overhead of cbind is now damaging to cbind S3 methods > system.time(cbind(m,m)) user system elapsed 0.043 0.034 0.077 [~175% of the original time] Wouldn't a better near-term approach involve writing S3 methods to dispatch on. > methods:::bind_activation(FALSE) > library(Matrix) > M <- Matrix(1:10) > cbind(M,M) M M [1,] ? ? > cbind.dgeMatrix <- function(..., deparse.level=1) methods:::cbind(..., > deparse.level=deparse.level) > cbind(M,M) 10 x 2 Matrix of class "dgeMatrix" [,1] [,2] [1,]11 [2,]22 [3,]33 [4,]44 [5,]55 [6,]66 [7,]77 [8,]88 [9,]99 [10,] 10 10 # this approach "does no harm" to regular S3 methods > system.time(cbind(m,m)) user system elapsed 0.028 0.017 0.045 Obviously this negates part of the S4 dispatch value, but that can be had by calling cbind2 directly. Jeff -- Jeffrey Ryan [EMAIL PROTECTED] ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Date + difftime (PR#13369)
Full_Name: G. Grothendieck
Version: 2.8.0
OS: Vista
Submission from: (NULL) (69.63.52.10)
Get rid of the annoying warning. This is supposed to be valid according to
?Ops.Date (shown at end):
> today <- Sys.Date()
> tomorrow <- today + 1
> dt <- tomorrow - today
> today + dt
[1] "2008-12-05"
Warning message:
Incompatible methods ("+.Date", "Ops.difftime") for "+"
---
Operators on the Date Class
Description
Operators for the "Date" class.
There is an Ops method and specific methods for + and - for the Date class.
Usage
date + x
date - x
date1 lop date2
Arguments
date date objects
date1, date2 date objects or character vectors. (Character vectors are converted
by as.Date.)
x a numeric vector (in days) or an object of class "difftime".
lop One of ==, !=, <, <=, > or >=.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recent snapshot tarballs of R-devel don't compile
Hi, Trying to compile one of the latest snapshot tarballs of R-devel gives me the following error (64-bit openSUSE 10.3): ... make[2]: Entering directory `/loc/home/biocbuild/bbs-2.4-bioc/R/src/library/Recommended' make[2]: *** No rule to make target `VR.ts', needed by `stamp-recommended'. Stop. make[2]: Leaving directory `/loc/home/biocbuild/bbs-2.4-bioc/R/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/loc/home/biocbuild/bbs-2.4-bioc/R/src/library/Recommended' make: *** [stamp-recommended] Error 2 Maybe because these tarballs don't contain the symlinks that are normally defined in the src/library/Recommended/ folder? Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
