Re: [Rd] problem with zero-weighted observations in predict.lm?
Prof Brian Ripley wrote: > > I think you will find that 'n' is used in several ways in predict.lm, > and since NA-handling was introduced in R 1.8.0 they may differ in > value. So the safest route seems to be to change just 'n' in > > df <- n - p Yes, that seems to fix things. Will commit to R-devel shortly. -p -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with zero-weighted observations in predict.lm?
Peter Dalgaard wrote: > Prof Brian Ripley wrote: > >> I think you will find that 'n' is used in several ways in predict.lm, >> and since NA-handling was introduced in R 1.8.0 they may differ in >> value. So the safest route seems to be to change just 'n' in >> >> df <- n - p > > Yes, that seems to fix things. Will commit to R-devel shortly. > > -p > Spoke too soon, it fixes Bill's case, but breaks one of the regression tests! In fact this goes deeper, summary.lm special-cases the same zero-rank case by using length(residuals), so it also miscalculates with zero weights: > fit <- lm(y~0,weights=c(0,rep(1,9))) > summary(fit) Call: lm(formula = y ~ 0, weights = c(0, rep(1, 9))) Residuals: Min 1Q Median 3Q Max -1.95428 -1.40571 -0.42378 -0.05795 1.05518 No Coefficients Residual standard error: 1.119 on 10 degrees of freedom Hum. lm() actually returns df.residual, AFAICS in all cases, now why don't we just use that throughout -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build wiped my computer (from R-help)
NOTE: Now submitted to R-devel, as this seems more appropriate.
I may have spoken too soon about this having been fixed. (see below).
If I create another "unusual but not 'invalid'" filename in the R subdirectory,
the
behaviour is different from that reported below, and is similar to the original
poster's
output (the third "unlink" command, where "xyz" was "~"):
circa> ls -al RColorBrewer/R
total 140
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:57residuals.MCMCglmm.R?xyz
drwxr-xr-x 2 ray ecs 4096 Jul 29 12:02 ./
drwxr-xr-x 5 ray ecs 4096 Jul 29 11:49 ../
-rwxr-xr-x 1 ray ecs 43988 Jul 29 09:57 ColorBrewer.R*
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005 ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:58 residuals.MCMCglmm.R
circa>
circa>
circa> R CMD build RColorBrewer
* checking for file 'RColorBrewer/DESCRIPTION' ... OK
* preparing 'RColorBrewer':
* checking DESCRIPTION meta-information ... OK
* checking whether 'INDEX' is up-to-date ... NO
* use '--force' to overwrite the existing 'INDEX'
* removing junk files
unlink RColorBrewer/R/ ColorBrewer.R~
unlink RColorBrewer/R/ColorBrewer.R
unlink RColorBrewer/R/ residuals.MCMCglmm.R
xyz
unlink RColorBrewer/R/residuals.MCMCglmm.R
unlink RColorBrewer/R/ColorBrewer.R~
rmdir RColorBrewer/R
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'RColorBrewer_1.0-3.tar.gz'
circa>
Ray Brownrigg
On Thu, 29 Jul 2010, Ray Brownrigg wrote:
> On Thu, 29 Jul 2010, Duncan Murdoch wrote:
> > On 28/07/2010 10:01 AM, Jarrod Hadfield wrote:
> > > Hi Marc,
> > >
> > > Thanks for the info on recovery - most of it can pieced together from
> > > backups but a quick, cheap and easy method of recovery would have been
> > > nicer.
> > >
> > > My main concern is that this could happen again and that the "bug" is
> > > not limited to R 2.9. I would think that an accidental carriage return
> > > at the end of a file name (even a temporary one) would be a reasonably
> > > common phenomenon (I'm surprised I hadn't done it before).
> >
> > If you can put together a recipe to reproduce the problem (or a less
> > extreme version of R deleting files it shouldn't), we'll certainly fix
> > it. But so far all we've got are guesses about what might have gone
> > wrong, and I don't think anyone has been able to reproduce the problem
> > on current R.
>
> Duncan:
>
> It looks to me like it has already been fixed, if indeed that was the
> problem. In R-2.10.1, I tried to reproduce the problem (using
> RColorBrewer, since that was the smallest package I have a local copy of),
> and the build produced this:
>
> * removing junk files
> * excluding invalid files from 'RColorBrewer'
> Subdirectory 'R' contains invalid file names:
> residuals.MCMCglmm.R xyz
>
> where the space shown between the "R" and the "xyz" was a newline
> character. [I didn't dare try using a "~" :-)]
>
> Ray Brownrigg
>
> > Duncan Murdoch
> >
> > > Cheers,
> > >
> > > Jarrod
> > >
> > > On 28 Jul 2010, at 14:04, Marc Schwartz wrote:
> > > > Jarrod,
> > > >
> > > > Noting your exchange with Martin, Martin brings up a point that
> > > > certainly I missed, which is that somehow the tilde ('~') character
> > > > got into the chain of events. As Martin noted, on Linuxen/Unixen
> > > > (including OSX), the tilde, when used in the context of file name
> > > > globbing, refers to your home directory. Thus, a command such as:
> > > >
> > > > ls ~
> > > >
> > > > will list the files in your home directory. Similarly:
> > > >
> > > > rm ~
> > > >
> > > > will remove the files there as well. If the -rf argument is added,
> > > > then the deletion becomes recursive through that directory tree,
> > > > which appears to be the case here.
> > > >
> > > > I am unclear, as Martin appears to be, as to the steps that caused
> > > > this to happen. That may yet be related in some fashion to Duncan's
> > > > hypothesis.
> > > >
> > > > That being said, the use of the tilde character as a suffix to
> > > > denote that a file is a backup version, is not limited to Fedora or
> > > > Linux, for that matter. It is quite common for many text editors
> > > > (eg. Emacs) to use this. As a result, it is also common for many
> > > > applications to ignore files that have a tilde suffix.
> > > >
> > > > Based upon your follow up posts to the original thread, it would
> > > > seem that you do not have any backups. The default ext3 file system
> > > > that is used on modern Linuxen, by design, makes it a bit more
> > > > difficult to recover deleted files. This is due to the unlinking of
> > > > file metadata at the file system data structure level, as opposed to
> > > > simply marking the file as deleted in the directory structures, as
> > > > happens on Windows.
> > > >
> > > > There is a utility called ext3undel
> > > > (http://projects.izzysoft.de/trac/ext3undel ), which is a wrapper of
> > > > sorts to other
Re: [Rd] CRAN updates?
On 27.07.2010 22:15, Simon Urbanek wrote: On Jul 27, 2010, at 9:56 AM, Dominick Samperi wrote: It appears that after a package is updated the CRAN binaries for some OS's are built automatically and shortly after the update, while other OS's are not updated for some time (weeks in some cases). Is the process automated or is it partially manual for some OS's (like Windows/w64 and Mac OS X)? It is automated on Mac OS X (currently R builds start at midnight and package builds at 2am ET). ... as well as automated under all flavours for/of Windows. Uwe Cheers, Simon PS: If you see delays (i.e. the check result is not available more than two days after the package is available on CRAN) it's a good idea to contact the corresponding binary maintainer (for OS X it's me) since things can break (packages can run mad and external servers can die). __ 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] R CMD check - "there is no package called"
On 26.07.2010 02:00, Simon Urbanek wrote:
On Jul 24, 2010, at 9:02 AM, John Hendrickx wrote:
I'm trying to update my "perturb" package to get rid of some small warning
messages. The examples in "perturb" use the "Duncan" dataset from the "car"
package and I have "car" installed in R. But when I run "R CMD check", I get an
error message
require("car")
Loading required package: car
Warning in library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE, :
there is no package called 'car'
data(Duncan)
Warning in data(Duncan) : data set 'Duncan' not found
This is very strange, the example works fine if I just run it in R. This is the
example from the perturb.rd file:
\examples{
require("car")
data(Duncan)
attach(Duncan)
m1<-lm(prestige~income+education)
...
I'm using R 2.11.1 under Ubuntu 10.04. Perhaps the problem is related to the
packages being installed in my home directory. I've create an ~/.Renviron file
with
R_LIBS_USER="/home/john/lib/R/library"
I've also tried creating an environment variable "export
R_LIBRARY_DIR=/home/john/lib/R/library/" before running R CMD check.
The correct name is R_LIBS
... and from "Writing R Extensions":
Note: R CMD check and R CMD build run R with '--vanilla', so none of the
user's startup files are read. If you need R_LIBS set (to find packages
in a non-standard library) you will need to set it in the environment.
Uwe
Cheers,
Simon
That made
no difference. Can anyone point me in the right direction? Do I have to install
packages in R_HOME?
[[alternative HTML version deleted]]
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build wiped my computer (from R-help)
On 28/07/2010 8:10 PM, Ray Brownrigg wrote:
NOTE: Now submitted to R-devel, as this seems more appropriate.
I may have spoken too soon about this having been fixed. (see below).
If I create another "unusual but not 'invalid'" filename in the R subdirectory, the
behaviour is different from that reported below, and is similar to the original poster's
output (the third "unlink" command, where "xyz" was "~"):
circa> ls -al RColorBrewer/R
total 140
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:57residuals.MCMCglmm.R?xyz
Ray clarified to me that this filename was "residuals.MCMCglmm.R"
preceded by 3 spaces and followed by a carriage return and "xyz".
drwxr-xr-x 2 ray ecs 4096 Jul 29 12:02 ./
drwxr-xr-x 5 ray ecs 4096 Jul 29 11:49 ../
-rwxr-xr-x 1 ray ecs 43988 Jul 29 09:57 ColorBrewer.R*
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005 ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:58 residuals.MCMCglmm.R
circa>
circa>
circa> R CMD build RColorBrewer
* checking for file 'RColorBrewer/DESCRIPTION' ... OK
* preparing 'RColorBrewer':
* checking DESCRIPTION meta-information ... OK
* checking whether 'INDEX' is up-to-date ... NO
* use '--force' to overwrite the existing 'INDEX'
* removing junk files
unlink RColorBrewer/R/ ColorBrewer.R~
unlink RColorBrewer/R/ColorBrewer.R
unlink RColorBrewer/R/ residuals.MCMCglmm.R
xyz
That certainly looks bad. I can't reproduce it on Windows; it doesn't
allow that filename. So I'll have to leave this for a Unix-alike user.
Duncan Murdoch
unlink RColorBrewer/R/residuals.MCMCglmm.R
unlink RColorBrewer/R/ColorBrewer.R~
rmdir RColorBrewer/R
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'RColorBrewer_1.0-3.tar.gz'
circa>
Ray Brownrigg
On Thu, 29 Jul 2010, Ray Brownrigg wrote:
On Thu, 29 Jul 2010, Duncan Murdoch wrote:
On 28/07/2010 10:01 AM, Jarrod Hadfield wrote:
Hi Marc,
Thanks for the info on recovery - most of it can pieced together from
backups but a quick, cheap and easy method of recovery would have been
nicer.
My main concern is that this could happen again and that the "bug" is
not limited to R 2.9. I would think that an accidental carriage return
at the end of a file name (even a temporary one) would be a reasonably
common phenomenon (I'm surprised I hadn't done it before).
If you can put together a recipe to reproduce the problem (or a less
extreme version of R deleting files it shouldn't), we'll certainly fix
it. But so far all we've got are guesses about what might have gone
wrong, and I don't think anyone has been able to reproduce the problem
on current R.
Duncan:
It looks to me like it has already been fixed, if indeed that was the
problem. In R-2.10.1, I tried to reproduce the problem (using
RColorBrewer, since that was the smallest package I have a local copy of),
and the build produced this:
* removing junk files
* excluding invalid files from 'RColorBrewer'
Subdirectory 'R' contains invalid file names:
residuals.MCMCglmm.R xyz
where the space shown between the "R" and the "xyz" was a newline
character. [I didn't dare try using a "~" :-)]
Ray Brownrigg
Duncan Murdoch
Cheers,
Jarrod
On 28 Jul 2010, at 14:04, Marc Schwartz wrote:
Jarrod,
Noting your exchange with Martin, Martin brings up a point that
certainly I missed, which is that somehow the tilde ('~') character
got into the chain of events. As Martin noted, on Linuxen/Unixen
(including OSX), the tilde, when used in the context of file name
globbing, refers to your home directory. Thus, a command such as:
ls ~
will list the files in your home directory. Similarly:
rm ~
will remove the files there as well. If the -rf argument is added,
then the deletion becomes recursive through that directory tree,
which appears to be the case here.
I am unclear, as Martin appears to be, as to the steps that caused
this to happen. That may yet be related in some fashion to Duncan's
hypothesis.
That being said, the use of the tilde character as a suffix to
denote that a file is a backup version, is not limited to Fedora or
Linux, for that matter. It is quite common for many text editors
(eg. Emacs) to use this. As a result, it is also common for many
applications to ignore files that have a tilde suffix.
Based upon your follow up posts to the original thread, it would
seem that you do not have any backups. The default ext3 file system
that is used on modern Linuxen, by design, makes it a bit more
difficult to recover deleted files. This is due to the unlinking of
file metadata at the file system data structure level, as opposed to
simply marking the file as deleted in the directory structures, as
happens on Windows.
There is a utility called ext3undel
(http://projects.izzysoft.de/trac/ext3undel ), which is a wrapper of
sorts to other undelete utilities such as PhotoRec and foremost. I
have not used it/them, so cannot speak from pers
Re: [Rd] Telling R CMD check where to find libraries
On 20.07.2010 17:18, Thaler, Thorn, LAUSANNE, Applied Mathematics wrote: Hello everybody, Currently I'm developing a library, which uses some functions from another package (namely plotrix). Consequently, I listed this dependency in the DESCRIPTION file. When I try to run "R CMD check mypackage", the check fails, for the library plotrix cannot be found on the system. As far as I understood "R CMD check" uses --vanilla implicitly, thus, no startup files are read. Hence, plotrix cannot be found by "R CMD check", since it is only installed locally (I've no admin privileges on this machine) and the path to the library is given in .Rprofile, which in turn is not read by "R CMD check". If I provide the flag "-l /path/to/site/libs", it works as expected but with the side effect that the test installation is carried out in this directory as well, which I do not like either (this directory should contain only stable packages and not packages which are still under construction). So which possibilities do I have? Set the environment variable R_LIBS to point to that library. Uwe Ligges BR Thorn __ 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] problem with zero-weighted observations in predict.lm?
I believe that I now has this nailed down (a couple of further issues raised their head). Committed to r-devel. -pd On Jul 29, 2010, at 10:11 AM, Peter Dalgaard wrote: > Peter Dalgaard wrote: >> Prof Brian Ripley wrote: >> >>> I think you will find that 'n' is used in several ways in predict.lm, >>> and since NA-handling was introduced in R 1.8.0 they may differ in >>> value. So the safest route seems to be to change just 'n' in >>> >>> df <- n - p >> >> Yes, that seems to fix things. Will commit to R-devel shortly. >> >> -p >> > > Spoke too soon, it fixes Bill's case, but breaks one of the regression > tests! > > In fact this goes deeper, summary.lm special-cases the same zero-rank > case by using length(residuals), so it also miscalculates with zero weights: > >> fit <- lm(y~0,weights=c(0,rep(1,9))) >> summary(fit) > > Call: > lm(formula = y ~ 0, weights = c(0, rep(1, 9))) > > Residuals: > Min 1Q Median 3Q Max > -1.95428 -1.40571 -0.42378 -0.05795 1.05518 > > No Coefficients > > Residual standard error: 1.119 on 10 degrees of freedom > > > > Hum. lm() actually returns df.residual, AFAICS in all cases, now why > don't we just use that throughout > > > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Using 'dimname names' in aperm() and apply()
I think that the "dimname names" of tables and arrays could make
aperm() and apply() (and probably some other functions) easier to use.
(dimname names are, for example, created by table() )
The use would be something like:
--
x <-table( from=sample(3,100,rep=T), to=sample(5,100,rep=T))
trans <- x / apply(x,"from",sum)
y <- aperm( trans, c("from","to") )
z <- aperm(y, c("to","from") )
res <-apply( y, "to", sum)
--
This makes the array much easier to handle than having to keep track
which dimension currently means what.
For aperm and apply, the change seems very simple - one new function,
and an additional line in each.
--
dimnum.from.dimnamename <- function(A, dimensions)
{
if( is.character(dimensions) ) {
n <- names(dimnames(A))
if( !is.null(n) ) {
dimnum <- seq( along=n)
names(dimnum) <- n
dimensions <- dimnum[dimensions]
}
}
dimensions
}
aperm <- function (a, perm, resize = TRUE)
{
if (missing(perm))
perm <- integer(0L)
perm <- dimnum.from.dimnamename( a, perm) # this line was added to aperm
.Internal(aperm(a, perm, resize))
}
apply <- function (X, MARGIN, FUN, ...)
{
FUN <- match.fun(FUN)
d <- dim(X)
dl <- length(d)
if (dl == 0L)
stop("dim(X) must have a positive length")
ds <- 1L:dl
if (length(oldClass(X)))
X <- if (dl == 2)
as.matrix(X)
else as.array(X)
d <- dim(X)
dn <- dimnames(X)
MARGIN <- dimnum.from.dimnamename( X,MARGIN ) # this line was added to apply
s.call <- ds[-MARGIN]
s.ans <- ds[MARGIN]
d.call <- d[-MARGIN]
d.ans <- d[MARGIN]
dn.call <- dn[-MARGIN]
dn.ans <- dn[MARGIN]
d2 <- prod(d.ans)
if (d2 == 0L) {
newX <- array(vector(typeof(X), 1L), dim = c(prod(d.call),
1L))
ans <- FUN(if (length(d.call) < 2L)
newX[, 1]
else array(newX[, 1L], d.call, dn.call), ...)
return(if (is.null(ans)) ans else if (length(d.ans) <
2L) ans[1L][-1L] else array(ans, d.ans, dn.ans))
}
newX <- aperm(X, c(s.call, s.ans))
dim(newX) <- c(prod(d.call), d2)
ans <- vector("list", d2)
if (length(d.call) < 2L) {
if (length(dn.call))
dimnames(newX) <- c(dn.call, list(NULL))
for (i in 1L:d2) {
tmp <- FUN(newX[, i], ...)
if (!is.null(tmp))
ans[[i]] <- tmp
}
}
else for (i in 1L:d2) {
tmp <- FUN(array(newX[, i], d.call, dn.call), ...)
if (!is.null(tmp))
ans[[i]] <- tmp
}
ans.list <- is.recursive(ans[[1L]])
l.ans <- length(ans[[1L]])
ans.names <- names(ans[[1L]])
if (!ans.list)
ans.list <- any(unlist(lapply(ans, length)) != l.ans)
if (!ans.list && length(ans.names)) {
all.same <- sapply(ans, function(x) identical(names(x),
ans.names))
if (!all(all.same))
ans.names <- NULL
}
len.a <- if (ans.list)
d2
else length(ans <- unlist(ans, recursive = FALSE))
if (length(MARGIN) == 1L && len.a == d2) {
names(ans) <- if (length(dn.ans[[1L]]))
dn.ans[[1L]]
return(ans)
}
if (len.a == d2)
return(array(ans, d.ans, dn.ans))
if (len.a && len.a%%d2 == 0L) {
if (is.null(dn.ans))
dn.ans <- vector(mode = "list", length(d.ans))
dn.ans <- c(list(ans.names), dn.ans)
return(array(ans, c(len.a%/%d2, d.ans), if (!all(sapply(dn.ans,
is.null))) dn.ans))
}
return(ans)
}
--
Thanks,
Michael
--
Michael Lachmann, Max Planck institute of evolutionary anthropology
Deutscher Platz. 6, 04103 Leipzig, Germany
Tel: +49-341-3550521, Fax: +49-341-3550555
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using 'dimname names' in aperm() and apply()
It's not that simple. These are base functions so
- adding utility functions to base is undesirable
- efficiency matters
- any change (including adding a function!) needs corresponding
documentation.
- this needs much better error checking.
- dimnum.from.dimnamename is rather inefficient: a simple call to
match() will do the job. (And we do have seq_along !)
I've been tidying up aperm(), and there this is as simple to do at C
level (and more efficient). For apply(), something like
if (is.character(MARGIN)) {
if(is.null(dnn <- names(dn)))
stop("'X' must have named dimnames")
MARGIN <- match(MARGIN, dnn)
if (any(is.na(MARGIN)))
stop("not all elements of 'perm' are names of dimensions")
}
Thanks for the suggestions: a version will appear in R-devel in due
course.
On Thu, 29 Jul 2010, Michael Lachmann wrote:
I think that the "dimname names" of tables and arrays could make
aperm() and apply() (and probably some other functions) easier to use.
(dimname names are, for example, created by table() )
The use would be something like:
--
x <-table( from=sample(3,100,rep=T), to=sample(5,100,rep=T))
trans <- x / apply(x,"from",sum)
Here for efficiency use rowSums()
y <- aperm( trans, c("from","to") )
z <- aperm(y, c("to","from") )
res <-apply( y, "to", sum)
--
This makes the array much easier to handle than having to keep track
which dimension currently means what.
For aperm and apply, the change seems very simple - one new function,
and an additional line in each.
--
dimnum.from.dimnamename <- function(A, dimensions)
{
if( is.character(dimensions) ) {
n <- names(dimnames(A))
if( !is.null(n) ) {
dimnum <- seq( along=n)
names(dimnum) <- n
dimensions <- dimnum[dimensions]
}
}
dimensions
}
aperm <- function (a, perm, resize = TRUE)
{
if (missing(perm))
perm <- integer(0L)
perm <- dimnum.from.dimnamename( a, perm) # this line was added to aperm
.Internal(aperm(a, perm, resize))
}
apply <- function (X, MARGIN, FUN, ...)
{
FUN <- match.fun(FUN)
d <- dim(X)
dl <- length(d)
if (dl == 0L)
stop("dim(X) must have a positive length")
ds <- 1L:dl
if (length(oldClass(X)))
X <- if (dl == 2)
as.matrix(X)
else as.array(X)
d <- dim(X)
dn <- dimnames(X)
MARGIN <- dimnum.from.dimnamename( X,MARGIN ) # this line was added to apply
s.call <- ds[-MARGIN]
s.ans <- ds[MARGIN]
d.call <- d[-MARGIN]
d.ans <- d[MARGIN]
dn.call <- dn[-MARGIN]
dn.ans <- dn[MARGIN]
d2 <- prod(d.ans)
if (d2 == 0L) {
newX <- array(vector(typeof(X), 1L), dim = c(prod(d.call),
1L))
ans <- FUN(if (length(d.call) < 2L)
newX[, 1]
else array(newX[, 1L], d.call, dn.call), ...)
return(if (is.null(ans)) ans else if (length(d.ans) <
2L) ans[1L][-1L] else array(ans, d.ans, dn.ans))
}
newX <- aperm(X, c(s.call, s.ans))
dim(newX) <- c(prod(d.call), d2)
ans <- vector("list", d2)
if (length(d.call) < 2L) {
if (length(dn.call))
dimnames(newX) <- c(dn.call, list(NULL))
for (i in 1L:d2) {
tmp <- FUN(newX[, i], ...)
if (!is.null(tmp))
ans[[i]] <- tmp
}
}
else for (i in 1L:d2) {
tmp <- FUN(array(newX[, i], d.call, dn.call), ...)
if (!is.null(tmp))
ans[[i]] <- tmp
}
ans.list <- is.recursive(ans[[1L]])
l.ans <- length(ans[[1L]])
ans.names <- names(ans[[1L]])
if (!ans.list)
ans.list <- any(unlist(lapply(ans, length)) != l.ans)
if (!ans.list && length(ans.names)) {
all.same <- sapply(ans, function(x) identical(names(x),
ans.names))
if (!all(all.same))
ans.names <- NULL
}
len.a <- if (ans.list)
d2
else length(ans <- unlist(ans, recursive = FALSE))
if (length(MARGIN) == 1L && len.a == d2) {
names(ans) <- if (length(dn.ans[[1L]]))
dn.ans[[1L]]
return(ans)
}
if (len.a == d2)
return(array(ans, d.ans, dn.ans))
if (len.a && len.a%%d2 == 0L) {
if (is.null(dn.ans))
dn.ans <- vector(mode = "list", length(d.ans))
dn.ans <- c(list(ans.names), dn.ans)
return(array(ans, c(len.a%/%d2, d.ans), if (!all(sapply(dn.ans,
is.null))) dn.ans))
}
return(ans)
}
--
Thanks,
Michael
--
Michael Lachmann, Max Planck institute of evolutionary anthropology
Deutscher Platz. 6, 04103 Leipzig, Germany
Tel: +49-341-3550521, Fax: +49-341-3550555
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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, UK
[Rd] RODBC sqlSave not all columns
Hello, How can I make sqlSave only to write a subset of columns. I've a (MS-Access) table with columns A, B, C en D and if I send a sqlSave command with a data frame with columns A, B en D I get the message: Error in odbcUpdate(channel, query, mydata, coldata[m, ], test = test, : missing columns in 'data' Calls: sqlSave -> sqlwrite -> odbcUpdate (The columns in my table are all defined optional) I can add a dummy column to my data frame with name C and value NA and sqlSave will be happy, but is there another way to do this? Arguments to sqlSave? I can't find them in the documentation. Regards. -- View this message in context: http://r.789695.n4.nabble.com/RODBC-sqlSave-not-all-columns-tp2306570p2306570.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] HowTo get callback on destroy of grDevices::windows()
Hi On 27/07/2010 7:49 a.m., rrich...@fh-lausitz.de wrote: I'm build with the usage of the tcltk/tcltk2 package a gui which is started with rscript.exe. At this gui the user is able to open and close plot windows. Now I'm looking for a way that a r function is called when a grDevices::windows window is closed. Is there a way to attach a callback function or so, which would be triggert if the user click at close of the grDevices::window? My workarround is to check continues the open windows with the tcl command after, but it's no good workarround. I don't think this is possible with standard R graphics devices. Have you taken a look at the 'tkrplot' package; if you produce a tcltk window with an R graphics device embedded, instead of opening/closing raw R graphics devices, perhaps you could gain more control over the opening/closing of the window (?) Paul thanks roland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
