[Rd] Cannot Change Function (PR#14041)
Full_Name: Michael Aaron Karsh
Version: 2.8.0
OS: Windows XP
Submission from: (NULL) (75.61.102.255)
Whenever I try changing a function, it keeps coming up with the same error
message.
I have the function
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state for the log
sum approach
if(((Im(Tot_log_sum))!=0)|Re(Tot_log_sum)<=log(1/4)/log(2)) {return(0)}
if(((Im(Tot_log_sum))==0)&&((Re(Tot_log_sum))>log(1/4)/log(2))&&((Re(Tot_log_sum))(log(3/4)/log(2)))&&((Re(Tot_log_sum))log(5/4)/log(2))&&((Re(Tot_log_sum))log(7/4)/log(2)))
{return(4)}
}
When I try to run it in the loop:
for (j in 1:length(BB_mean_ref)){ # find copy number states (0 for
homozygous
deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single amplification,
4 for multiple amplification)
state_log_sum[j]=CN_state_log_sum(Tot_log_sum[j])
state_sum_log[j]=CN_state_sum_log(Tot_sum_log[j])
}
I get the error message:
Error in Im(Tot_sum_log) != 0 || Re(Tot_sum_log) <- 2 :
could not find function "||<-"
Originally, I had defined the function:
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state for the log
sum approach
if(Im(Tot_log_sum)!=0||Re(Tot_log_sum)<-2) return(0)
if(Im(Tot_log_sum)==0&&Re(Tot_log_sum)>-2)&&Re(Tot_log_sum)<-.4150375)
return(1)
if(Im(Tot_log_sum)==0&&Re(Tot_log_sum)>-.4150375&&Re(Tot_log_sum)<.3219281)
return(2)
if(Im(Tot_log_sum)==0&&Re(Tot_log_sum)>.3219281&&Re(Tot_log_sum)<.807355)
return(3)
if(Im(Tot_log_sum)==0&&Re(Tot_log_sum)>.807355) return(4)
}
When I tried:
for (j in 1:length(BB_mean_ref)){ # find copy number states (0 for
homozygous
deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single amplification,
4 for multiple amplification)
state_log_sum[j]=CN_state_log_sum(Tot_log_sum[j])
state_sum_log[j]=CN_state_sum_log(Tot_sum_log[j])
}
I get the error message:
Error in Im(Tot_sum_log) != 0 || Re(Tot_sum_log) <- 2 :
could not find function "||<-"
I then tried changing the function to:
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state for the log
sum approach
if((Im(Tot_log_sum)!=0)||(Re(Tot_log_sum)<-2)) return(0)
if((Im(Tot_log_sum)==0)&&(Re(Tot_log_sum)>-2))&&(Re(Tot_log_sum)<-.4150375))
return(1)
if((Im(Tot_log_sum)==0)&&(Re(Tot_log_sum)>-.4150375)&&(Re(Tot_log_sum)<.3219281))
return(2)
if((Im(Tot_log_sum)==0)&&(Re(Tot_log_sum)>.3219281)&&(Re(Tot_log_sum)<.807355))
return(3)
if((Im(Tot_log_sum)==0)&&(Re(Tot_log_sum)>.807355)) return(4)
}
I got the same error message.
I then remembered that <- is used to make assignments, when what I wanted to do
was compare one expression to a negative number. I then tried changing the
function to:
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state for the log
sum approach
if(((Im(Tot_log_sum))!=0)|Re(Tot_log_sum)<=log(1/4)/log(2)) {return(0)}
if(((Im(Tot_log_sum))==0)&&((Re(Tot_log_sum))>log(1/4)/log(2))&&((Re(Tot_log_sum))(log(3/4)/log(2)))&&((Re(Tot_log_sum))log(5/4)/log(2))&&((Re(Tot_log_sum))log(7/4)/log(2)))
{return(4)}
}
I got the same error message.
I then tried removing the function using the command:
rm(CN_state_log_sum) and then putting in the function again:
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state for the log
sum approach
if(((Im(Tot_log_sum))!=0)|Re(Tot_log_sum)<=log(1/4)/log(2)) {return(0)}
if(((Im(Tot_log_sum))==0)&&((Re(Tot_log_sum))>log(1/4)/log(2))&&((Re(Tot_log_sum))(log(3/4)/log(2)))&&((Re(Tot_log_sum))log(5/4)/log(2))&&((Re(Tot_log_sum))log(7/4)/log(2)))
{return(4)}
}
Same error message.
I tried removing the function again, and then tried saving the new workspace and
the workspace image when I closed R so that it would remember that that function
had been removed when I would open R again. I then opened R again and defined
the same function again. Again, when I tried running it, I got the same error
message.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] library gplots : heatmap.2 reordering broken (PR#14037)
Full_Name: Niels
Version: <= 2.10.0
OS: Windows
Submission from: (NULL) (76.182.102.23)
The reordering option in library gplots : heatmap.2 is broken. Re-ordering of
the dendrogram is supposed to work by providing a vector of ordering weighs in
Rowv. However, the tests in line 131 and 174 are not adequate for Rowv being a
vector and therefore break the code. The same is probably true for Colv. Also,
there is a typo in line 137 ("dedrogram" instead of "dendrogram").
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Registered S3 methods not found: Documentation bug or anomaly in function update or ... ?
Well, > swiss.lm Call: lm.default(formula = Fertility ~ Education + Examination, data = swiss) That means the call is registered as lm.default and update calls that one (and it is hidden in your namespace. You can fix it on your side so that the call is registered as lm(.) in the lm object. Anyway, I think it is a bit dangerous to redefine lm() the way you did it. Best wishes, Uwe Ulrike Grömping wrote: Dear expeRts, I recently asked for help on an issue with S3 methods for lm. The issue was (in DoE.base 0.9-4) that function update from package stats would return an error whenever DoE.base was loaded, complaining that lm.default was not found (e.g. require(DoE.base) swiss.lm <- lm(Fertility~Education+Examination, swiss) upd.swiss.lm <- update(swiss.lm, .~.-Examination) ). In version 0.9-4 of DoE.base, I had followed the recommendations of Section 1.6.2 of "Writing R extensions", exporting the generic function lm and registering the methods (lm.design and lm.default) with S3method but not separately exporting them in the namespace file. Not having received help fast, I decided to try to explicitly export the method functions lm.design and lm.default. This did in fact remove the issue with not finding lm.default when using function update, and I have uploaded this fixed version as 0.9-5. Is it generally advisable to also export the method functions (i.e. should section 1.6.2 of "Writing R extensions" be revised) ? Or is there an anomaly in function update ? Or ...? Explanations are appreciated. Thanks and regards, Ulrike __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Registered S3 methods not found: Documentation bug or anomaly in function update or ... ?
Ah, thanks, now I understand the mode of operation and will work on a more robust fix than exporting the functions. Regards, Ulrike -- Original Message --- From: Uwe Ligges To: Ulrike Grömping Cc: r-devel@r-project.org Sent: Wed, 04 Nov 2009 12:19:59 +0100 Subject: Re: [Rd] Registered S3 methods not found: Documentation bug or anomaly in function update or ... ? > Well, > > > swiss.lm > > Call: > lm.default(formula = Fertility ~ Education + Examination, data = swiss) > > That means the call is registered as lm.default and update calls that > one (and it is hidden in your namespace. > > You can fix it on your side so that the call is registered as lm(.) > in the lm object. > > Anyway, I think it is a bit dangerous to redefine lm() the way you did it. > > Best wishes, > Uwe > > Ulrike Grömping wrote: > > Dear expeRts, > > > > I recently asked for help on an issue with S3 methods for lm. The issue > > was (in DoE.base 0.9-4) > > that function update from package stats would return an error whenever > > DoE.base was loaded, > > complaining that lm.default was not found > > (e.g. > > require(DoE.base) > > swiss.lm <- lm(Fertility~Education+Examination, swiss) > > upd.swiss.lm <- update(swiss.lm, .~.-Examination) > > ). > > > > In version 0.9-4 of DoE.base, I had followed the recommendations of > > Section 1.6.2 of "Writing R > > extensions", exporting the generic function lm and registering the > > methods (lm.design and lm.default) > > with S3method but not separately exporting them in the namespace file. > > Not having received help fast, I decided to try to explicitly export the > > method functions > > lm.design and lm.default. This did in fact remove the > > issue with not finding lm.default when using function update, and I have > > uploaded this fixed version > > as 0.9-5. > > > > Is it generally advisable to also export the method functions (i.e. > > should section > > 1.6.2 of "Writing R extensions" be revised) ? Or is there an anomaly in > > function update ? Or ...? > > Explanations are appreciated. > > > > Thanks and regards, Ulrike > > --- End of Original Message --- [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cannot Change Function (PR#14041)
What makes you think this is a bug in R?
Whenever I try changing a function, it keeps coming up with the same
error
message.
I have the function
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state
for the log
[...]
}
When I try to run it in the loop:
for (j in 1:length(BB_mean_ref)){ # find copy number states (0 for
homozygous
deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single
amplification,
4 for multiple amplification)
state_log_sum[j]=CN_state_log_sum(Tot_log_sum[j])
state_sum_log[j]=CN_state_sum_log(Tot_sum_log[j])
}
I get the error message:
Error in Im(Tot_sum_log) != 0 || Re(Tot_sum_log) <- 2 :
could not find function "||<-"
The error message indicates that the problem happens in the function
CN_state_sum_log() rather than CN_state_log_sum(), so it's hardly
surprising that changing the latter doesn't have any effect.
My guess: you've go a condition (Re(Tot_sum_log)<-2), which is
mistaken for the assignment operator "<-" by the R parser. Adding some
whitespace (Re(Tot_sum_log) < -2) should help both R and human readers
to make sense of it.
Best,
Stefan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cascade option for dev.new?
I frequently run scripts that generate multiple graphs. Unless you specify a
specific window location, dev.new superimposes all new graphics windows exactly
on top of each other. It would be nice to have a "cascade=TRUE" option in
dev.new to prevent windows from being hidden. A hasty approximation to this is
the following function:
# utility function to prevent overlapping plot windows
cascade <- function( k=dev.cur(),x0=300,y0=50,dx=30,dy=30){
dev.new( xpos=x0+k*dx, ypos=y0+k*dy);
invisible() }
x <- seq(-10,10,.1); y <- sin(x)
plot(x,y,type='l',main='first plot')
cascade()
plot(x,y,type='l',main='second plot')
John Nolan
Math/Stat Dept.
American University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error in install.packages() (PR#14042)
Full_Name: Michael Spiegel
Version: 2.10
OS: Windows Vista
Submission from: (NULL) (76.104.24.156)
The following error is produced when attempting to call install.packages. Here
is the results of the traceback:
> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
Error in f(res) : invalid subscript type 'list'
> traceback()
7: f(res)
6: available.packages(contriburl = contriburl, method = method)
5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
method = method, available = available, destdir = destdir,
dependencies = dependencies, ...)
4: install.packages(pkgs = c("OpenMx"), repos = repos)
3: eval.with.vis(expr, envir, enclos)
2: eval.with.vis(ei, envir)
1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
I've tracked the error down to somewhere in available.packages defined in
src\library\utils\R\packages.R. I am guessing that the error in version 2.10
has something to do with the change: "available.packages() gains a 'filters'
argument for specifying the filtering operations performed on the packages found
in the repositories."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] s4 generic issue
I'm hoping that someone with deeper insight into S4 than I,
that is to say virtually everyone reading this list, could help
resolve the following problem in SparseM. We have
setGeneric("backsolve",
function(r, x, k = NULL, upper.tri = NULL, transpose = NULL,
twice = TRUE, ...)
standardGeneric("backsolve"),
useAsDefault= function(r, x, k = ncol(r), upper.tri = TRUE,
transpose = FALSE, twice = TRUE, ...)
base::backsolve(r, x, k = ncol(r), upper.tri = TRUE,
transpose = FALSE, ...))
and then proceed to use setMethod for a class matrix.csr.chol.
However, this seems
to cause problems in the following instance: if one does the following
require(lars)
require(SparseM)
example(lars)
[snip]
lars> object3 <- lars(x,y,type="for") # Can use abbreviations
Error in base::backsolve(r, x, k = ncol(r), upper.tri = TRUE,
transpose = FALSE, :
NA/NaN/Inf in foreign function call (arg 4)
> traceback()
10: .C("bakslv", t = r, ldt = nrow(r), n = k, b = x, ldb = k, nb = nb,
x = matrix(0, k, nb), job = job, info = integer(1L), DUP =
FALSE,
PACKAGE = "base")
9: base::backsolve(r, x, k = ncol(r), upper.tri = TRUE, transpose =
FALSE,
...)
8: backsolve(R, backsolvet(R, Sign[positive]))
7: backsolve(R, backsolvet(R, Sign[positive]))
6: nnls.lars(active, Sign, R, directions, Gram[active, active],
trace = trace, use.Gram = TRUE, eps = eps)
5: lars(x, y, type = "for")
4: eval.with.vis(expr, envir, enclos)
3: eval.with.vis(ei, envir)
2: source(zfile, local, echo = echo, prompt.echo = paste(prompt.prefix,
getOption("prompt"), sep = ""), continue.echo = paste
(prompt.prefix,
getOption("continue"), sep = ""), verbose = verbose,
max.deparse.length = Inf,
encoding = encoding, skip.echo = skips, keep.source = TRUE)
1: example(lars)
So clearly base::backsolve is getting called as would be desired in
this case,
but something is rotten in the way arguments are being passed.
I'm aware that the R-extensions manual suggests another strategy than
setGeneric for making generics, but I would like to understand what is
going
wrong here.
Roger
url:www.econ.uiuc.edu/~rogerRoger Koenker
emailrkoen...@uiuc.eduDepartment of Economics
vox: 217-333-4558University of Illinois
fax: 217-244-6678Urbana, IL 61801
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error in install.packages() (PR#14042)
On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
Full_Name: Michael Spiegel
Version: 2.10
OS: Windows Vista
Submission from: (NULL) (76.104.24.156)
The following error is produced when attempting to call install.packages. Here
is the results of the traceback:
source('http://openmx.psyc.virginia.edu/getOpenMx.R')
Error in f(res) : invalid subscript type 'list'
traceback()
7: f(res)
6: available.packages(contriburl = contriburl, method = method)
5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
method = method, available = available, destdir = destdir,
dependencies = dependencies, ...)
4: install.packages(pkgs = c("OpenMx"), repos = repos)
3: eval.with.vis(expr, envir, enclos)
2: eval.with.vis(ei, envir)
1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
I've tracked the error down to somewhere in available.packages defined in
src\library\utils\R\packages.R. I am guessing that the error in version 2.10
has something to do with the change: "available.packages() gains a 'filters'
argument for specifying the filtering operations performed on the packages found
in the repositories."
I can reproduce this, and yes, it is happening in one of the filters.
I'd guess it happens because your repository has only one entry (a
missed "drop=FALSE" somewhere maybe) or because the filter is finding no
matches. I'll track down the details and fix it.
Thanks for the report.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error in install.packages() (PR#14042)
On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
Full_Name: Michael Spiegel
Version: 2.10
OS: Windows Vista
Submission from: (NULL) (76.104.24.156)
The following error is produced when attempting to call install.packages. Here
is the results of the traceback:
source('http://openmx.psyc.virginia.edu/getOpenMx.R')
Error in f(res) : invalid subscript type 'list'
traceback()
7: f(res)
6: available.packages(contriburl = contriburl, method = method)
5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
method = method, available = available, destdir = destdir,
dependencies = dependencies, ...)
4: install.packages(pkgs = c("OpenMx"), repos = repos)
3: eval.with.vis(expr, envir, enclos)
2: eval.with.vis(ei, envir)
1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
I've tracked the error down to somewhere in available.packages defined in
src\library\utils\R\packages.R. I am guessing that the error in version 2.10
has something to do with the change: "available.packages() gains a 'filters'
argument for specifying the filtering operations performed on the packages found
in the repositories."
I've found the error, and will fix and commit to R-devel and R-patched.
For future reference: the problem was that it assigned the result of
sapply() to a subset of a vector. Normally sapply() simplifies its
result to a vector, but in this case the result was empty, so sapply()
returned an empty list; assigning a list to a vector coerced the vector
to a list, and then the "invalid subscript type 'list'" came soon after.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error in install.packages() (PR#14042)
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
> Sent: Wednesday, November 04, 2009 8:47 AM
> To: michael.m.spie...@gmail.com
> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] error in install.packages() (PR#14042)
>
> On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> > Full_Name: Michael Spiegel
> > Version: 2.10
> > OS: Windows Vista
> > Submission from: (NULL) (76.104.24.156)
> >
> >
> > The following error is produced when attempting to call
> install.packages. Here
> > is the results of the traceback:
> >
> >> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> > Error in f(res) : invalid subscript type 'list'
> >> traceback()
> > 7: f(res)
> > 6: available.packages(contriburl = contriburl, method = method)
> > 5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl =
> contriburl,
> >method = method, available = available, destdir = destdir,
> >dependencies = dependencies, ...)
> > 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> > 3: eval.with.vis(expr, envir, enclos)
> > 2: eval.with.vis(ei, envir)
> > 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
> >
> > I've tracked the error down to somewhere in
> available.packages defined in
> > src\library\utils\R\packages.R. I am guessing that the
> error in version 2.10
> > has something to do with the change: "available.packages()
> gains a 'filters'
> > argument for specifying the filtering operations performed
> on the packages found
> > in the repositories."
>
> I've found the error, and will fix and commit to R-devel and
> R-patched.
>
> For future reference: the problem was that it assigned the result of
> sapply() to a subset of a vector. Normally sapply() simplifies its
> result to a vector, but in this case the result was empty, so
> sapply()
> returned an empty list; assigning a list to a vector coerced
> the vector
> to a list, and then the "invalid subscript type 'list'" came
> soon after.
I've run into this sort of problem a lot (0-long input to sapply
causes it to return list()). A related problem is that when sapply's
FUN doesn't always return the type of value you expect for some
corner case then sapply won't do the expected simplication. If
sapply had an argument that gave the expected form of FUN's output
then sapply could (a) die if some call to FUN didn't return something
of that form and (b) return a 0-long object of the correct form
if sapply's X has length zero so FUN is never called. E.g.,
sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
third iteration
sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
logical(0)
Another benefit of sapply knowing the type of FUN's return value is
that it wouldn't have to waste space creating a list of FUN's return
values but could stuff them directly into the final output structure.
A list of n scalar doubles is 4.5 times bigger than double(n) and the
factor is 9.0 for integers and logicals.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
>
> Duncan Murdoch
>
> __
> 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] s4 generic issue
If you mean us to run the code you supplied:
1. There are two generic backsolve() functions, one in the gobal
environment and one in SparseM:
> showMethods(backsolve)
Function: backsolve (package .GlobalEnv)
r="ANY"
r="matrix"
(inherited from: r="ANY")
> showMethods(SparseM::backsolve)
Function: backsolve (package SparseM)
r="ANY"
r="matrix.csr.chol"
2. Package "lars" does not (unfortunately) have a NAMESPACE, so calls
from lars will get the version without a special method. This is
generally a recipe for trouble, but does not seem to be the issue in
this case.
3. A little inspection with options(error=recover) suggests the
computations screwed up some time before the actual call here (the
rather opaque error message is complaining because the x argument,
returned by backsolvet(), has NaNs and an Inf in it). Since
backsolvet() calls backsolve() with transpose=TRUE, it won't be happy
with your default method, which ignores the transpose= argument. Did
you really mean to do that? (Again, this would not show up in lars if
that package had a NAMESPACE).
I think the last point may explain your problem. It has nothing to do
with S4 generics, only with the general "keep it simple" advice.
Cheers,
John
Roger Koenker wrote:
I'm hoping that someone with deeper insight into S4 than I,
that is to say virtually everyone reading this list, could help
resolve the following problem in SparseM. We have
setGeneric("backsolve",
function(r, x, k = NULL, upper.tri = NULL, transpose = NULL,
twice = TRUE, ...)
standardGeneric("backsolve"),
useAsDefault= function(r, x, k = ncol(r), upper.tri = TRUE,
transpose = FALSE, twice = TRUE, ...)
base::backsolve(r, x, k = ncol(r), upper.tri = TRUE,
transpose = FALSE, ...))
and then proceed to use setMethod for a class matrix.csr.chol.
However, this seems
to cause problems in the following instance: if one does the following
require(lars)
require(SparseM)
example(lars)
[snip]
lars> object3 <- lars(x,y,type="for") # Can use abbreviations
Error in base::backsolve(r, x, k = ncol(r), upper.tri = TRUE,
transpose = FALSE, :
NA/NaN/Inf in foreign function call (arg 4)
> traceback()
10: .C("bakslv", t = r, ldt = nrow(r), n = k, b = x, ldb = k, nb = nb,
x = matrix(0, k, nb), job = job, info = integer(1L), DUP = FALSE,
PACKAGE = "base")
9: base::backsolve(r, x, k = ncol(r), upper.tri = TRUE, transpose =
FALSE,
...)
8: backsolve(R, backsolvet(R, Sign[positive]))
7: backsolve(R, backsolvet(R, Sign[positive]))
6: nnls.lars(active, Sign, R, directions, Gram[active, active],
trace = trace, use.Gram = TRUE, eps = eps)
5: lars(x, y, type = "for")
4: eval.with.vis(expr, envir, enclos)
3: eval.with.vis(ei, envir)
2: source(zfile, local, echo = echo, prompt.echo = paste(prompt.prefix,
getOption("prompt"), sep = ""), continue.echo =
paste(prompt.prefix,
getOption("continue"), sep = ""), verbose = verbose,
max.deparse.length = Inf,
encoding = encoding, skip.echo = skips, keep.source = TRUE)
1: example(lars)
So clearly base::backsolve is getting called as would be desired in
this case,
but something is rotten in the way arguments are being passed.
I'm aware that the R-extensions manual suggests another strategy than
setGeneric for making generics, but I would like to understand what is
going
wrong here.
Roger
url:www.econ.uiuc.edu/~rogerRoger Koenker
emailrkoen...@uiuc.eduDepartment of Economics
vox: 217-333-4558University of Illinois
fax: 217-244-6678Urbana, IL 61801
__
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] error in install.packages() (PR#14042)
On 11/4/2009 12:15 PM, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
Sent: Wednesday, November 04, 2009 8:47 AM
To: michael.m.spie...@gmail.com
Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
Subject: Re: [Rd] error in install.packages() (PR#14042)
On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> Full_Name: Michael Spiegel
> Version: 2.10
> OS: Windows Vista
> Submission from: (NULL) (76.104.24.156)
>
>
> The following error is produced when attempting to call
install.packages. Here
> is the results of the traceback:
>
>> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> Error in f(res) : invalid subscript type 'list'
>> traceback()
> 7: f(res)
> 6: available.packages(contriburl = contriburl, method = method)
> 5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl =
contriburl,
>method = method, available = available, destdir = destdir,
>dependencies = dependencies, ...)
> 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> 3: eval.with.vis(expr, envir, enclos)
> 2: eval.with.vis(ei, envir)
> 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
>
> I've tracked the error down to somewhere in
available.packages defined in
> src\library\utils\R\packages.R. I am guessing that the
error in version 2.10
> has something to do with the change: "available.packages()
gains a 'filters'
> argument for specifying the filtering operations performed
on the packages found
> in the repositories."
I've found the error, and will fix and commit to R-devel and
R-patched.
For future reference: the problem was that it assigned the result of
sapply() to a subset of a vector. Normally sapply() simplifies its
result to a vector, but in this case the result was empty, so
sapply()
returned an empty list; assigning a list to a vector coerced
the vector
to a list, and then the "invalid subscript type 'list'" came
soon after.
I've run into this sort of problem a lot (0-long input to sapply
causes it to return list()). A related problem is that when sapply's
FUN doesn't always return the type of value you expect for some
corner case then sapply won't do the expected simplication. If
sapply had an argument that gave the expected form of FUN's output
then sapply could (a) die if some call to FUN didn't return something
of that form and (b) return a 0-long object of the correct form
if sapply's X has length zero so FUN is never called. E.g.,
sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
third iteration
sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
logical(0)
Another benefit of sapply knowing the type of FUN's return value is
that it wouldn't have to waste space creating a list of FUN's return
values but could stuff them directly into the final output structure.
A list of n scalar doubles is 4.5 times bigger than double(n) and the
factor is 9.0 for integers and logicals.
That sounds like a good idea. It would be a bit of work, because the
current sapply depends on lapply while this would need its own internal
implementation: but it would probably be worthwhile.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inconsistent behavior for logical vectors when using apply (" TRUE")
Hello, X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE)) X letters flag 1 a TRUE 2 b FALSE 3 c TRUE apply(X, 1, as.list) [[1]] [[1]]$letters [1] "a" [[1]]$flag [1] " TRUE" [[2]] [[2]]$letters [1] "b" [[2]]$flag [1] "FALSE" [[3]] [[3]]$letters [1] "c" [[3]]$flag [1] " TRUE" Notice how TRUE becomes " TRUE" and FALSE becomes "FALSE". Not sure why TRUE gets an extra whitespace in front. Checked with R-2.10.0, but can reproduce the behavior as far back as R-2.8.1. Adrian Dragulescu sessionInfo() R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.10.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistent behavior for logical vectors when using apply (" TRUE")
The apply function was meant to work on matrices and arrays, when you use it on
a data frame, the frame is first converted to a matrix. Since your data frame
has columns of different modes, the logical column is converted to character
and the matrix is of the single mode character. That is what you are seeing.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Adrian Dragulescu
> Sent: Wednesday, November 04, 2009 12:45 PM
> To: r-devel
> Subject: [Rd] inconsistent behavior for logical vectors when using
> apply (" TRUE")
>
>
> Hello,
>
> > X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE))
> > X
>letters flag
> 1 a TRUE
> 2 b FALSE
> 3 c TRUE
> > apply(X, 1, as.list)
> [[1]]
> [[1]]$letters
> [1] "a"
>
> [[1]]$flag
> [1] " TRUE"
>
>
> [[2]]
> [[2]]$letters
> [1] "b"
>
> [[2]]$flag
> [1] "FALSE"
>
>
> [[3]]
> [[3]]$letters
> [1] "c"
>
> [[3]]$flag
> [1] " TRUE"
>
> Notice how TRUE becomes " TRUE" and FALSE becomes "FALSE". Not sure
> why
> TRUE gets an extra whitespace in front.
>
> Checked with R-2.10.0, but can reproduce the behavior as far back as
> R-2.8.1.
>
> Adrian Dragulescu
>
> > sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
> States.1252
> [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_2.10.0
>
> __
> 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] error in install.packages() (PR#14042)
I agree it is a good idea, but a new name seems justified to avoid
confusion.
On Wed, 4 Nov 2009, Duncan Murdoch wrote:
On 11/4/2009 12:15 PM, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Duncan Murdoch
Sent: Wednesday, November 04, 2009 8:47 AM
To: michael.m.spie...@gmail.com
Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
Subject: Re: [Rd] error in install.packages() (PR#14042)
On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> Full_Name: Michael Spiegel
> Version: 2.10
> OS: Windows Vista
> Submission from: (NULL) (76.104.24.156)
> > > The following error is produced when attempting to call
install.packages. Here
> is the results of the traceback:
> >> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> Error in f(res) : invalid subscript type 'list'
>> traceback()
> 7: f(res)
> 6: available.packages(contriburl = contriburl, method = method)
> 5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl, >
method = method, available = available, destdir = destdir, >
dependencies = dependencies, ...)
> 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> 3: eval.with.vis(expr, envir, enclos)
> 2: eval.with.vis(ei, envir)
> 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
> > I've tracked the error down to somewhere in available.packages defined
in
> src\library\utils\R\packages.R. I am guessing that the error in version
2.10
> has something to do with the change: "available.packages() gains a
'filters'
> argument for specifying the filtering operations performed on the
packages found
> in the repositories."
I've found the error, and will fix and commit to R-devel and R-patched.
For future reference: the problem was that it assigned the result of
sapply() to a subset of a vector. Normally sapply() simplifies its result
to a vector, but in this case the result was empty, so sapply() returned
an empty list; assigning a list to a vector coerced the vector to a list,
and then the "invalid subscript type 'list'" came soon after.
I've run into this sort of problem a lot (0-long input to sapply
causes it to return list()). A related problem is that when sapply's
FUN doesn't always return the type of value you expect for some
corner case then sapply won't do the expected simplication. If
sapply had an argument that gave the expected form of FUN's output
then sapply could (a) die if some call to FUN didn't return something
of that form and (b) return a 0-long object of the correct form
if sapply's X has length zero so FUN is never called. E.g.,
sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
third iteration
sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
logical(0)
Another benefit of sapply knowing the type of FUN's return value is
that it wouldn't have to waste space creating a list of FUN's return
values but could stuff them directly into the final output structure.
A list of n scalar doubles is 4.5 times bigger than double(n) and the
factor is 9.0 for integers and logicals.
That sounds like a good idea. It would be a bit of work, because the current
sapply depends on lapply while this would need its own internal
implementation: but it would probably be worthwhile.
Duncan Murdoch
__
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistent behavior for logical vectors when using apply (" TRUE")
Well documented in ?as.matrix.
Ignore my previous post.
On Wed, 4 Nov 2009, Greg Snow wrote:
The apply function was meant to work on matrices and arrays, when you use it on
a data frame, the frame is first converted to a matrix. Since your data frame
has columns of different modes, the logical column is converted to character
and the matrix is of the single mode character. That is what you are seeing.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of Adrian Dragulescu
Sent: Wednesday, November 04, 2009 12:45 PM
To: r-devel
Subject: [Rd] inconsistent behavior for logical vectors when using
apply (" TRUE")
Hello,
X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE))
X
letters flag
1 a TRUE
2 b FALSE
3 c TRUE
apply(X, 1, as.list)
[[1]]
[[1]]$letters
[1] "a"
[[1]]$flag
[1] " TRUE"
[[2]]
[[2]]$letters
[1] "b"
[[2]]$flag
[1] "FALSE"
[[3]]
[[3]]$letters
[1] "c"
[[3]]$flag
[1] " TRUE"
Notice how TRUE becomes " TRUE" and FALSE becomes "FALSE". Not sure
why
TRUE gets an extra whitespace in front.
Checked with R-2.10.0, but can reproduce the behavior as far back as
R-2.8.1.
Adrian Dragulescu
sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
__
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
[Rd] sapply improvements
On 11/4/2009 12:15 PM, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
Sent: Wednesday, November 04, 2009 8:47 AM
To: michael.m.spie...@gmail.com
Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
Subject: Re: [Rd] error in install.packages() (PR#14042)
On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> Full_Name: Michael Spiegel
> Version: 2.10
> OS: Windows Vista
> Submission from: (NULL) (76.104.24.156)
>
>
> The following error is produced when attempting to call
install.packages. Here
> is the results of the traceback:
>
>> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> Error in f(res) : invalid subscript type 'list'
>> traceback()
> 7: f(res)
> 6: available.packages(contriburl = contriburl, method = method)
> 5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl =
contriburl,
>method = method, available = available, destdir = destdir,
>dependencies = dependencies, ...)
> 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> 3: eval.with.vis(expr, envir, enclos)
> 2: eval.with.vis(ei, envir)
> 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
>
> I've tracked the error down to somewhere in
available.packages defined in
> src\library\utils\R\packages.R. I am guessing that the
error in version 2.10
> has something to do with the change: "available.packages()
gains a 'filters'
> argument for specifying the filtering operations performed
on the packages found
> in the repositories."
I've found the error, and will fix and commit to R-devel and
R-patched.
For future reference: the problem was that it assigned the result of
sapply() to a subset of a vector. Normally sapply() simplifies its
result to a vector, but in this case the result was empty, so
sapply()
returned an empty list; assigning a list to a vector coerced
the vector
to a list, and then the "invalid subscript type 'list'" came
soon after.
I've run into this sort of problem a lot (0-long input to sapply
causes it to return list()). A related problem is that when sapply's
FUN doesn't always return the type of value you expect for some
corner case then sapply won't do the expected simplication. If
sapply had an argument that gave the expected form of FUN's output
then sapply could (a) die if some call to FUN didn't return something
of that form and (b) return a 0-long object of the correct form
if sapply's X has length zero so FUN is never called. E.g.,
sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
third iteration
sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
logical(0)
Another benefit of sapply knowing the type of FUN's return value is
that it wouldn't have to waste space creating a list of FUN's return
values but could stuff them directly into the final output structure.
A list of n scalar doubles is 4.5 times bigger than double(n) and the
factor is 9.0 for integers and logicals.
What do you think of the behaviour of the sapply function below? (I
wouldn't put it into R as it is, I'd translate it to C code to avoid the
lapply call; but I'd like to get the behaviour right before doing that.)
This one checks that the length() and typeof() results are consistent.
If the FUN.VALUE has names, those are used (but it doesn't require the
names from FUN to match).
Duncan Murdoch
sapply <- function(X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE,
FUN.VALUE)
{
FUN <- match.fun(FUN)
answer <- lapply(X, FUN, ...)
if(USE.NAMES && is.character(X) && is.null(names(answer)))
names(answer) <- X
if(simplify) {
if (missing(FUN.VALUE)) {
if ((!length(answer))
|| length(common.len <- unique(unlist(lapply(answer,
length != 1L)
return(answer)
common.names <- names(answer[[1L]])
} else {
common.len <- length(FUN.VALUE)
common.type <- typeof(FUN.VALUE)
common.names <- names(FUN.VALUE)
if (length(answer)) {
if (any( unlist(lapply(answer, length)) != common.len ))
stop(sprintf("%s values must be of length %d", "FUN",
common.len))
if (any( unlist(lapply(answer, typeof)) != common.type ))
stop(sprintf("%s values must be of type '%s'", "FUN",
common.type))
if (is.null(common.names))
common.names <- names(answer[[1L]])
} else if (length(FUN.VALUE) > 1)
return(array(FUN.VALUE[0], dim=c(common.len, 0),
dimnames= if(!is.null(common.names))
list(common.names,character(0
else
return(FUN.VALUE[0])
}
if(common.len == 1L)
unlist(answer, recursive = FALSE)
else if(common.len > 1L)
array(unlist(answer, recursive
Re: [Rd] inconsistent behavior for logical vectors when using apply (" TRUE")
This happens in as.matrix(), which gets called by apply().
When you've got a mixed-mode dataframe like this, as.matrix() converts
everything to character. But, the rules it uses for each column don't
seem to be entirely consistent regarding whether columns are
space-padded to make each element have the same number of characters.
The way it works out, logical mode columns are passed through format(),
which space-pads by default. Factor columns are passed through
as.vector(), and character-mode columns are left alone. The result is
that some columns come out space-padded, and some don't, depending on
their original mode.
To get greater control of this, you theoretically should be able to do
something like apply(as.matrix(format(X, justify="none")), ...),
except that format() seems to ignore the justify argument for logical
vectors, e.g.:
> format(c(T,F,T))
[1] " TRUE" "FALSE" " TRUE"
> format(c(T,F,T), justify="none")
[1] " TRUE" "FALSE" " TRUE"
>
If it's really important for you to get this to work the way you want,
you can convert the logical column of the data frame using as.character
(see the end of the example below).
Here's an example that shows probably far more than you wanted to know:
> X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE),
codef=c("a","ab","abcd"), codec=I(c("x", "xy", "xyz")))
> sapply(X, class)
letters flag codef codec
"factor" "logical" "factor""AsIs"
> as.matrix(X)
letters flagcodef codec
[1,] "a" " TRUE" "a""x"
[2,] "b" "FALSE" "ab" "xy"
[3,] "c" " TRUE" "abcd" "xyz"
> unclass(format(X))
$letters
[1] "a" "b" "c"
$flag
[1] " TRUE" "FALSE" " TRUE"
$codef
[1] "a""ab" "abcd"
$codec
[1] "x" "xy" "xyz"
attr(,"row.names")
[1] "1" "2" "3"
> unclass(format(X, justify="left"))
$letters
[1] "a" "b" "c"
$flag
[1] " TRUE" "FALSE" " TRUE"
$codef
[1] "a " "ab " "abcd"
$codec
[1] "x " "xy " "xyz"
attr(,"row.names")
[1] "1" "2" "3"
>
> # The only way I can see to get the logical column converted to
character without padding:
> X1 <- X
> X1$flag <- as.character(X1$flag)
> as.matrix(X1)
letters flagcodef codec
[1,] "a" "TRUE" "a""x"
[2,] "b" "FALSE" "ab" "xy"
[3,] "c" "TRUE" "abcd" "xyz"
>
Adrian Dragulescu wrote:
Hello,
X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE))
X
letters flag
1 a TRUE
2 b FALSE
3 c TRUE
apply(X, 1, as.list)
[[1]]
[[1]]$letters
[1] "a"
[[1]]$flag
[1] " TRUE"
[[2]]
[[2]]$letters
[1] "b"
[[2]]$flag
[1] "FALSE"
[[3]]
[[3]]$letters
[1] "c"
[[3]]$flag
[1] " TRUE"
Notice how TRUE becomes " TRUE" and FALSE becomes "FALSE". Not sure
why TRUE gets an extra whitespace in front.
Checked with R-2.10.0, but can reproduce the behavior as far back as
R-2.8.1.
Adrian Dragulescu
sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
__
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] error in install.packages() (PR#14042)
> -Original Message-
> From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
> Sent: Wednesday, November 04, 2009 12:19 PM
> To: Duncan Murdoch
> Cc: William Dunlap; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] error in install.packages() (PR#14042)
>
> I agree it is a good idea, but a new name seems justified to avoid
> confusion.
If you could decide on a good name for the new argument
and the format of the data in it I could implement it in
S+ and keep R & S+ compatible. The format issue seems
bigger to me. Giving a prototype of the expected return
value is very flexible but wastes a bit of space. I propose
treating it much as the value of FUN(X[[1]]) is treated.
If the prototype included names then those could become the row
names of the matrix output, instead of the names on the
actual return values. (I would ignore the row names
when asking if the expected return value sufficiently resembled
the actual one.) E.g., the current
> sapply(split(log(1:10), rep(letters[1:2],c(3,7))), quantile,
(1:2)/3)
ab
33.3% 0.4620981 1.791759
66.7% 0.8283022 2.079442
with THE.NEW.ARGUMENT=c(T1=0,T2=0) would return
ab
T1 0.4620981 1.791759
T2 0.8283022 2.079442
(I don't know if that behavior is needed, but it is a correlary
of using THE.NEW.ARGUMENT instead of FUN(X[[1]]) as the source
of row names and perhaps other data.)
Should THE.NEW.ARGUMENT's mode have to match exactly the mode
of FUN(X[[i]]) or should it just be possible to coerce the value
of FUN(X[[i]]) to it?
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
>
> On Wed, 4 Nov 2009, Duncan Murdoch wrote:
>
> > On 11/4/2009 12:15 PM, William Dunlap wrote:
> >>> -Original Message-
> >>> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org]
> >>> On Behalf Of Duncan Murdoch
> >>> Sent: Wednesday, November 04, 2009 8:47 AM
> >>> To: michael.m.spie...@gmail.com
> >>> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
> >>> Subject: Re: [Rd] error in install.packages() (PR#14042)
> >>>
> >>> On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> >>> > Full_Name: Michael Spiegel
> >>> > Version: 2.10
> >>> > OS: Windows Vista
> >>> > Submission from: (NULL) (76.104.24.156)
> >>> > > > The following error is produced when attempting to call
> >>> install.packages. Here
> >>> > is the results of the traceback:
> >>> > >> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> >>> > Error in f(res) : invalid subscript type 'list'
> >>> >> traceback()
> >>> > 7: f(res)
> >>> > 6: available.packages(contriburl = contriburl, method = method)
> >>> > 5: .install.winbinary(pkgs = pkgs, lib = lib,
> contriburl = contriburl, >
> >>> method = method, available = available, destdir = destdir, >
> >>> dependencies = dependencies, ...)
> >>> > 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> >>> > 3: eval.with.vis(expr, envir, enclos)
> >>> > 2: eval.with.vis(ei, envir)
> >>> > 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
> >>> > > I've tracked the error down to somewhere in
> available.packages defined
> >>> in
> >>> > src\library\utils\R\packages.R. I am guessing that the
> error in version
> >>> 2.10
> >>> > has something to do with the change:
> "available.packages() gains a
> >>> 'filters'
> >>> > argument for specifying the filtering operations
> performed on the
> >>> packages found
> >>> > in the repositories."
> >>>
> >>> I've found the error, and will fix and commit to R-devel
> and R-patched.
> >>>
> >>> For future reference: the problem was that it assigned
> the result of
> >>> sapply() to a subset of a vector. Normally sapply()
> simplifies its result
> >>> to a vector, but in this case the result was empty, so
> sapply() returned
> >>> an empty list; assigning a list to a vector coerced the
> vector to a list,
> >>> and then the "invalid subscript type 'list'" came soon after.
> >>
> >> I've run into this sort of problem a lot (0-long input to sapply
> >> causes it to return list()). A related problem is that
> when sapply's
> >> FUN doesn't always return the type of value you expect for some
> >> corner case then sapply won't do the expected simplication. If
> >> sapply had an argument that gave the expected form of FUN's output
> >> then sapply could (a) die if some call to FUN didn't
> return something
> >> of that form and (b) return a 0-long object of the correct form
> >> if sapply's X has length zero so FUN is never called. E.g.,
> >>sapply(2:0, function(i)(11:20)[i],
> FUN.VALUE=integer(1)) # die on
> >> third iteration
> >>sapply(integer(0), function(i)i>0,
> FUN.VALUE=logical(1)) # return
> >> logical(0)
> >>
> >> Another benefit of sapply knowing the type of FUN's return value is
> >> that it wouldn't have to waste space creating a list of
> FUN's return
> >> values but could stuff them directly into the final output
> structure.
> >> A list of n sca
Re: [Rd] sapply improvements
S4 generics can specify a valueClass. Perhaps that could be used in
those cases.
On Wed, Nov 4, 2009 at 3:24 PM, Duncan Murdoch wrote:
> On 11/4/2009 12:15 PM, William Dunlap wrote:
>>>
>>> -Original Message-
>>> From: r-devel-boun...@r-project.org
>>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
>>> Sent: Wednesday, November 04, 2009 8:47 AM
>>> To: michael.m.spie...@gmail.com
>>> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
>>> Subject: Re: [Rd] error in install.packages() (PR#14042)
>>>
>>> On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
>>> > Full_Name: Michael Spiegel
>>> > Version: 2.10
>>> > OS: Windows Vista
>>> > Submission from: (NULL) (76.104.24.156)
>>> > > > The following error is produced when attempting to call
>>> > > > install.packages. Here
>>> > is the results of the traceback:
>>> > >> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
>>> > Error in f(res) : invalid subscript type 'list'
>>> >> traceback()
>>> > 7: f(res)
>>> > 6: available.packages(contriburl = contriburl, method = method)
>>> > 5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
>>> > > method = method, available = available, destdir = destdir, >
>>> > dependencies = dependencies, ...)
>>> > 4: install.packages(pkgs = c("OpenMx"), repos = repos)
>>> > 3: eval.with.vis(expr, envir, enclos)
>>> > 2: eval.with.vis(ei, envir)
>>> > 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
>>> > > I've tracked the error down to somewhere in available.packages
>>> > > defined in
>>> > src\library\utils\R\packages.R. I am guessing that the error in
>>> > version 2.10
>>> > has something to do with the change: "available.packages() gains a
>>> > 'filters'
>>> > argument for specifying the filtering operations performed on the
>>> > packages found
>>> > in the repositories."
>>>
>>> I've found the error, and will fix and commit to R-devel and R-patched.
>>>
>>> For future reference: the problem was that it assigned the result of
>>> sapply() to a subset of a vector. Normally sapply() simplifies its result
>>> to a vector, but in this case the result was empty, so sapply() returned an
>>> empty list; assigning a list to a vector coerced the vector to a list, and
>>> then the "invalid subscript type 'list'" came soon after.
>>
>> I've run into this sort of problem a lot (0-long input to sapply
>> causes it to return list()). A related problem is that when sapply's
>> FUN doesn't always return the type of value you expect for some
>> corner case then sapply won't do the expected simplication. If
>> sapply had an argument that gave the expected form of FUN's output
>> then sapply could (a) die if some call to FUN didn't return something
>> of that form and (b) return a 0-long object of the correct form
>> if sapply's X has length zero so FUN is never called. E.g.,
>> sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
>> third iteration
>> sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
>> logical(0)
>>
>> Another benefit of sapply knowing the type of FUN's return value is
>> that it wouldn't have to waste space creating a list of FUN's return
>> values but could stuff them directly into the final output structure.
>> A list of n scalar doubles is 4.5 times bigger than double(n) and the
>> factor is 9.0 for integers and logicals.
>
>
> What do you think of the behaviour of the sapply function below? (I
> wouldn't put it into R as it is, I'd translate it to C code to avoid the
> lapply call; but I'd like to get the behaviour right before doing that.)
>
> This one checks that the length() and typeof() results are consistent. If
> the FUN.VALUE has names, those are used (but it doesn't require the names
> from FUN to match).
>
> Duncan Murdoch
>
> sapply <- function(X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE,
> FUN.VALUE)
> {
> FUN <- match.fun(FUN)
> answer <- lapply(X, FUN, ...)
> if(USE.NAMES && is.character(X) && is.null(names(answer)))
> names(answer) <- X
> if(simplify) {
> if (missing(FUN.VALUE)) {
> if ((!length(answer))
> || length(common.len <- unique(unlist(lapply(answer,
> length != 1L)
> return(answer)
> common.names <- names(answer[[1L]])
> } else {
> common.len <- length(FUN.VALUE)
> common.type <- typeof(FUN.VALUE)
> common.names <- names(FUN.VALUE)
> if (length(answer)) {
> if (any( unlist(lapply(answer, length)) != common.len ))
> stop(sprintf("%s values must be of length %d", "FUN",
> common.len))
> if (any( unlist(lapply(answer, typeof)) != common.type ))
> stop(sprintf("%s values must be of type '%s'", "FUN",
> common.type))
> if (is.null(common.names))
> common.names <- names(answer[[1L]])
> } else if (length(FUN.VALUE) > 1)
>
Re: [Rd] sapply improvements
It looks good on following examples: > z <- split(log(1:10), rep(letters[1:2],c(3,7))) > sapply(z, length, FUN.VALUE=numeric(1)) Error in sapply(z, length, FUN.VALUE = numeric(1)) : FUN values must be of type 'double' (I'd like the error to say "... must be of type 'double', not 'integer'", to give the user a fuller diagnosis of the problem.) > sapply(z, range, FUN.VALUE=c(Min=0,Max=0)) ab Min 0.00 1.386294 Max 1.098612 2.302585 Exactly matching the typeof's and using the names for row.names on matrix output seem good to me. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > -Original Message- > From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] > Sent: Wednesday, November 04, 2009 12:24 PM > To: William Dunlap > Cc: michael.m.spie...@gmail.com; r-de...@stat.math.ethz.ch > Subject: sapply improvements > > On 11/4/2009 12:15 PM, William Dunlap wrote: > >> -Original Message- > >> From: r-devel-boun...@r-project.org > >> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch > >> Sent: Wednesday, November 04, 2009 8:47 AM > >> To: michael.m.spie...@gmail.com > >> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch > >> Subject: Re: [Rd] error in install.packages() (PR#14042) > >> ... > >> For future reference: the problem was that it assigned > the result of > >> sapply() to a subset of a vector. Normally sapply() > simplifies its > >> result to a vector, but in this case the result was empty, so > >> sapply() > >> returned an empty list; assigning a list to a vector coerced > >> the vector > >> to a list, and then the "invalid subscript type 'list'" came > >> soon after. > > > > I've run into this sort of problem a lot (0-long input to sapply > > causes it to return list()). A related problem is that > when sapply's > > FUN doesn't always return the type of value you expect for some > > corner case then sapply won't do the expected simplication. If > > sapply had an argument that gave the expected form of FUN's output > > then sapply could (a) die if some call to FUN didn't return > something > > of that form and (b) return a 0-long object of the correct form > > if sapply's X has length zero so FUN is never called. E.g., > >sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on > > third iteration > >sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return > > logical(0) > > > > Another benefit of sapply knowing the type of FUN's return value is > > that it wouldn't have to waste space creating a list of FUN's return > > values but could stuff them directly into the final output > structure. > > A list of n scalar doubles is 4.5 times bigger than > double(n) and the > > factor is 9.0 for integers and logicals. > > > What do you think of the behaviour of the sapply function below? (I > wouldn't put it into R as it is, I'd translate it to C code > to avoid the > lapply call; but I'd like to get the behaviour right before > doing that.) > > This one checks that the length() and typeof() results are > consistent. > If the FUN.VALUE has names, those are used (but it doesn't > require the > names from FUN to match). ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cannot Change Function (PR#14041)
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Stefan Evert
> Sent: Wednesday, November 04, 2009 4:40 AM
> To: michael_ka...@earthlink.net
> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Cannot Change Function (PR#14041)
>
> What makes you think this is a bug in R?
>
> > Whenever I try changing a function, it keeps coming up with the same
> > error
> > message.
> >
> > I have the function
> > CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state
> > for the log
> [...]
> > }
> >
> > When I try to run it in the loop:
> > for (j in 1:length(BB_mean_ref)){ # find copy number states (0 for
> > homozygous
> > deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single
> > amplification,
> > 4 for multiple amplification)
> > state_log_sum[j]=CN_state_log_sum(Tot_log_sum[j])
> > state_sum_log[j]=CN_state_sum_log(Tot_sum_log[j])
> > }
> > I get the error message:
> > Error in Im(Tot_sum_log) != 0 || Re(Tot_sum_log) <- 2 :
> > could not find function "||<-"
>
> The error message indicates that the problem happens in the function
> CN_state_sum_log() rather than CN_state_log_sum(), so it's hardly
> surprising that changing the latter doesn't have any effect.
>
> My guess: you've go a condition (Re(Tot_sum_log)<-2), which is
> mistaken for the assignment operator "<-" by the R parser. Adding some
> whitespace (Re(Tot_sum_log) < -2) should help both R and human readers
> to make sense of it.
Adding parentheses around the negative number is the only way to keep
such an expression robustly safe given the various whitespace alterations
that happen as such text passes through different parsers, editors,
mailers, proportional pitch font displays (which can fool human readers) ...
( ( Im(Tot_sum_log) != 0 ) || ( Re(Tot_sum_log) < (-2) ) )
Best
Steven McKinney
>
> Best,
> Stefan
>
> __
> 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] sapply improvements
> -Original Message- > From: William Dunlap > Sent: Wednesday, November 04, 2009 12:53 PM > To: 'Duncan Murdoch' > Cc: r-devel@r-project.org > Subject: RE: sapply improvements > > It looks good on following examples: > > > z <- split(log(1:10), rep(letters[1:2],c(3,7))) > > sapply(z, length, FUN.VALUE=numeric(1)) > Error in sapply(z, length, FUN.VALUE = numeric(1)) : > FUN values must be of type 'double' > > (I'd like the error to say "... must be of type 'double', > not 'integer'", to give the user a fuller diagnosis of > the problem.) If this new argument gets used much it may give a push towards getting functions to always return the same type of output. E.g., range(integer(0)) returns a numeric while range(integer(1)) an integer, resulting in: > z<-split(1:10, cut(log(1:10),breaks=0:4,include.lowest=TRUE)) > # z[[4]] is integer(0) > sapply(z,range,FUN.VALUE=integer(2)) Error in sapply(z, range, FUN.VALUE = integer(2)) : FUN values must be of type 'integer' In addition: Warning messages: 1: In min(x) : no non-missing arguments to min; returning Inf 2: In max(x) : no non-missing arguments to max; returning -Inf > > > sapply(z, range, FUN.VALUE=c(Min=0,Max=0)) >ab > Min 0.00 1.386294 > Max 1.098612 2.302585 > > Exactly matching the typeof's and using the names > for row.names on matrix output seem good to me. > > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > > -Original Message- > > From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] > > Sent: Wednesday, November 04, 2009 12:24 PM > > To: William Dunlap > > Cc: michael.m.spie...@gmail.com; r-de...@stat.math.ethz.ch > > Subject: sapply improvements > > > > On 11/4/2009 12:15 PM, William Dunlap wrote: > > >> -Original Message- > > >> From: r-devel-boun...@r-project.org > > >> [mailto:r-devel-boun...@r-project.org] On Behalf Of > Duncan Murdoch > > >> Sent: Wednesday, November 04, 2009 8:47 AM > > >> To: michael.m.spie...@gmail.com > > >> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch > > >> Subject: Re: [Rd] error in install.packages() (PR#14042) > > >> > ... > > >> For future reference: the problem was that it assigned > > the result of > > >> sapply() to a subset of a vector. Normally sapply() > > simplifies its > > >> result to a vector, but in this case the result was empty, so > > >> sapply() > > >> returned an empty list; assigning a list to a vector coerced > > >> the vector > > >> to a list, and then the "invalid subscript type 'list'" came > > >> soon after. > > > > > > I've run into this sort of problem a lot (0-long input to sapply > > > causes it to return list()). A related problem is that > > when sapply's > > > FUN doesn't always return the type of value you expect for some > > > corner case then sapply won't do the expected simplication. If > > > sapply had an argument that gave the expected form of FUN's output > > > then sapply could (a) die if some call to FUN didn't return > > something > > > of that form and (b) return a 0-long object of the correct form > > > if sapply's X has length zero so FUN is never called. E.g., > > >sapply(2:0, function(i)(11:20)[i], > FUN.VALUE=integer(1)) # die on > > > third iteration > > >sapply(integer(0), function(i)i>0, > FUN.VALUE=logical(1)) # return > > > logical(0) > > > > > > Another benefit of sapply knowing the type of FUN's > return value is > > > that it wouldn't have to waste space creating a list of > FUN's return > > > values but could stuff them directly into the final output > > structure. > > > A list of n scalar doubles is 4.5 times bigger than > > double(n) and the > > > factor is 9.0 for integers and logicals. > > > > > > What do you think of the behaviour of the sapply function > below? (I > > wouldn't put it into R as it is, I'd translate it to C code > > to avoid the > > lapply call; but I'd like to get the behaviour right before > > doing that.) > > > > This one checks that the length() and typeof() results are > > consistent. > > If the FUN.VALUE has names, those are used (but it doesn't > > require the > > names from FUN to match). > ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cannot Change Function (PR#14041)
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Stefan Evert
> Sent: Wednesday, November 04, 2009 4:40 AM
> To: michael_ka...@earthlink.net
> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Cannot Change Function (PR#14041)
>=20
> What makes you think this is a bug in R?
>=20
> > Whenever I try changing a function, it keeps coming up with the same
> > error
> > message.
> >
> > I have the function
> > CN_state_log_sum=3Dfunction(Tot_log_sum){ #estimate copy number state
> > for the log
> [...]
> > }
> >
> > When I try to run it in the loop:
> > for (j in 1:length(BB_mean_ref)){ # find copy number states (0 for
> > homozygous
> > deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single
> > amplification,
> > 4 for multiple amplification)
> > state_log_sum[j]=3DCN_state_log_sum(Tot_log_sum[j])
> > state_sum_log[j]=3DCN_state_sum_log(Tot_sum_log[j])
> > }
> > I get the error message:
> > Error in Im(Tot_sum_log) !=3D 0 || Re(Tot_sum_log) <- 2 :
> > could not find function "||<-"
>=20
> The error message indicates that the problem happens in the function
> CN_state_sum_log() rather than CN_state_log_sum(), so it's hardly
> surprising that changing the latter doesn't have any effect.
>=20
> My guess: you've go a condition (Re(Tot_sum_log)<-2), which is
> mistaken for the assignment operator "<-" by the R parser. Adding some
> whitespace (Re(Tot_sum_log) < -2) should help both R and human readers
> to make sense of it.
Adding parentheses around the negative number is the only way to keep
such an expression robustly safe given the various whitespace alterations
that happen as such text passes through different parsers, editors,
mailers, proportional pitch font displays (which can fool human readers) ..=
.
( ( Im(Tot_sum_log) !=3D 0 ) || ( Re(Tot_sum_log) < (-2) ) )
Best
Steven McKinney
>=20
> Best,
> Stefan
>=20
> __
> 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
[Rd] Possible bug in RTERM (PR#14043)
Full_Name: Andy Ashley
Version: 2.10.0
OS: Windows XP SP3
Submission from: (NULL) (91.105.184.105)
I am updating a legacy program which called Rterm from within Excel VBA as
follows:
Rexe = """C:\Program Files\R\R-2.4.0\bin\Rterm.exe"""
Roptions = ""
env_vars = " R_USER=" & dirname
cmdstring = Rexe & Roptions & env_vars
retval = Shell(cmdstring, 6)
R then executes .Rprofile
setwd(dirname)
source('run.R')
I had previously used R 2.4.0 and found that I could call functions in the base
package OK, but if I tried to call a function in stats, I got the error
message:
Error in eval.with.vis(expr,, envir, enclos) :
could not find function wilcox.test
This message is in the Rterm window which appears. If I then type search() in
this window, it tells me that package stats is loaded. I got around the problem
by specifically calling require(stats) at the start of the R code.
I upgraded the version of R used to 2.9.2 and I found that I now get the same
error message for base functions as well, but require(base) does not work. The
same problem occurs in R 2.10.0.
I have had to go back to using R2.4.0 in my application.
I realise that there is the Rexcel interface available, but it should still work
by calling Rterm.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply improvements
William Dunlap wrote: It looks good on following examples: z <- split(log(1:10), rep(letters[1:2],c(3,7))) sapply(z, length, FUN.VALUE=numeric(1)) Error in sapply(z, length, FUN.VALUE = numeric(1)) : FUN values must be of type 'double' (I'd like the error to say "... must be of type 'double', not 'integer'", to give the user a fuller diagnosis of the problem.) Umm, not following too closely, but would it not be preferable just to coerce in such cases? I can see a lot of issues of the if (x <= 0) NA else log(x) variety otherwise. sapply(z, range, FUN.VALUE=c(Min=0,Max=0)) ab Min 0.00 1.386294 Max 1.098612 2.302585 Exactly matching the typeof's and using the names for row.names on matrix output seem good to me. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com -Original Message- From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] Sent: Wednesday, November 04, 2009 12:24 PM To: William Dunlap Cc: michael.m.spie...@gmail.com; r-de...@stat.math.ethz.ch Subject: sapply improvements On 11/4/2009 12:15 PM, William Dunlap wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch Sent: Wednesday, November 04, 2009 8:47 AM To: michael.m.spie...@gmail.com Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch Subject: Re: [Rd] error in install.packages() (PR#14042) ... For future reference: the problem was that it assigned the result of sapply() to a subset of a vector. Normally sapply() simplifies its result to a vector, but in this case the result was empty, so sapply() returned an empty list; assigning a list to a vector coerced the vector to a list, and then the "invalid subscript type 'list'" came soon after. I've run into this sort of problem a lot (0-long input to sapply causes it to return list()). A related problem is that when sapply's FUN doesn't always return the type of value you expect for some corner case then sapply won't do the expected simplication. If sapply had an argument that gave the expected form of FUN's output then sapply could (a) die if some call to FUN didn't return something of that form and (b) return a 0-long object of the correct form if sapply's X has length zero so FUN is never called. E.g., sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on third iteration sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return logical(0) Another benefit of sapply knowing the type of FUN's return value is that it wouldn't have to waste space creating a list of FUN's return values but could stuff them directly into the final output structure. A list of n scalar doubles is 4.5 times bigger than double(n) and the factor is 9.0 for integers and logicals. What do you think of the behaviour of the sapply function below? (I wouldn't put it into R as it is, I'd translate it to C code to avoid the lapply call; but I'd like to get the behaviour right before doing that.) This one checks that the length() and typeof() results are consistent. If the FUN.VALUE has names, those are used (but it doesn't require the names from FUN to match). ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parse_Rd and/or lazyload problem
Here is a more stripped down variant generates and error on OS X for me:
mkEg <- function(tm) list(scrunge = as.POSIXct(tm))
extract <- function(db) {
e<- new.env()
lazyLoad(db, e)
as.list( e)
}
eg <- mkEg("2009-11-04 12:49:53")
eg1 <- mkEg("2009-11-04 12:49:28")
tools:::makeLazyLoadDB( eg, '/tmp/ll')
extract('/tmp/ll') # force; OK
tools:::makeLazyLoadDB( eg1, '/tmp/ll')
extract('/tmp/ll')
Changing the second set of /tmp/ll makes the symptom go away.
I believe this comes down to unintended use of the lazyload mechanism
-- in particular it is not intended that a database be rewritten after
it has been loaded. There is a chaching mechanism for improved
performance on slow file systems, and I believe what is happening is
that the new indices are being used to look in the old chached
data. There might be some merit in having lazyLoad call
R_lazyLoadDBflush.
luke
On Tue, 3 Nov 2009, Seth Falcon wrote:
Hi,
On 11/3/09 6:51 PM, mark.braving...@csiro.au wrote:
file.copy( 'd:/temp/Rdiff.Rd', 'd:/temp/scrunge.Rd') # Rdiff.Rd from
'tools' package source
eglist<- list( scrunge=parse_Rd( 'd:/temp/scrunge.Rd'))
tools:::makeLazyLoadDB( eglist, 'd:/temp/ll')
e<- new.env()
lazyLoad( 'd:/temp/ll', e)
as.list( e) # force; OK
eglist1<- list( scrunge=parse_Rd( 'd:/temp/Rdiff.Rd'))
tools:::makeLazyLoadDB( eglist1, 'd:/temp/ll')
e<- new.env()
lazyLoad( 'd:/temp/ll', e)
as.list( e) # Splat
It doesn't make any difference which file I process first; the error comes
the second time round.
If I adjust this example in terms of paths and run on OS X, I get the
following error on the second run:
as.list(e) # Splat
Error in as.list.environment(e) : internal error -3 in R_decompress1
I haven't looked further yet.
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply improvements
> -Original Message- > From: Peter Dalgaard [mailto:p.dalga...@biostat.ku.dk] > Sent: Wednesday, November 04, 2009 1:16 PM > To: William Dunlap > Cc: Duncan Murdoch; r-devel@r-project.org > Subject: Re: [Rd] sapply improvements > > William Dunlap wrote: > > It looks good on following examples: > > > >> z <- split(log(1:10), rep(letters[1:2],c(3,7))) > >> sapply(z, length, FUN.VALUE=numeric(1)) > > Error in sapply(z, length, FUN.VALUE = numeric(1)) : > > FUN values must be of type 'double' > > > > (I'd like the error to say "... must be of type 'double', > > not 'integer'", to give the user a fuller diagnosis of > > the problem.) > > Umm, not following too closely, but would it not be > preferable just to > coerce in such cases? I can see a lot of issues of the > > if (x <= 0) NA else log(x) > > variety otherwise. Would you only want it to coerce upwards to FUN.VALUES's type? E.g., allow sapply(z, length, FUN.VALUE=numeric(1)) to return a numeric vector but die on sapply(z, function(zi)as.complex(zi[1]), FUN.VALUE=numeric(1)) If the latter doesn't die should it return a complex or a numeric vector? (I'd say it needs to be numeric, but I'd prefer that it died.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > > >> sapply(z, range, FUN.VALUE=c(Min=0,Max=0)) > >ab > > Min 0.00 1.386294 > > Max 1.098612 2.302585 > > > > Exactly matching the typeof's and using the names > > for row.names on matrix output seem good to me. > > > > Bill Dunlap > > Spotfire, TIBCO Software > > wdunlap tibco.com > > > >> -Original Message- > >> From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] > >> Sent: Wednesday, November 04, 2009 12:24 PM > >> To: William Dunlap > >> Cc: michael.m.spie...@gmail.com; r-de...@stat.math.ethz.ch > >> Subject: sapply improvements > >> > >> On 11/4/2009 12:15 PM, William Dunlap wrote: > -Original Message- > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of > Duncan Murdoch > Sent: Wednesday, November 04, 2009 8:47 AM > To: michael.m.spie...@gmail.com > Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch > Subject: Re: [Rd] error in install.packages() (PR#14042) > > > ... > For future reference: the problem was that it assigned > >> the result of > sapply() to a subset of a vector. Normally sapply() > >> simplifies its > result to a vector, but in this case the result was empty, so > sapply() > returned an empty list; assigning a list to a vector coerced > the vector > to a list, and then the "invalid subscript type 'list'" came > soon after. > >>> I've run into this sort of problem a lot (0-long input to sapply > >>> causes it to return list()). A related problem is that > >> when sapply's > >>> FUN doesn't always return the type of value you expect for some > >>> corner case then sapply won't do the expected simplication. If > >>> sapply had an argument that gave the expected form of FUN's output > >>> then sapply could (a) die if some call to FUN didn't return > >> something > >>> of that form and (b) return a 0-long object of the correct form > >>> if sapply's X has length zero so FUN is never called. E.g., > >>>sapply(2:0, function(i)(11:20)[i], > FUN.VALUE=integer(1)) # die on > >>> third iteration > >>>sapply(integer(0), function(i)i>0, > FUN.VALUE=logical(1)) # return > >>> logical(0) > >>> > >>> Another benefit of sapply knowing the type of FUN's > return value is > >>> that it wouldn't have to waste space creating a list of > FUN's return > >>> values but could stuff them directly into the final output > >> structure. > >>> A list of n scalar doubles is 4.5 times bigger than > >> double(n) and the > >>> factor is 9.0 for integers and logicals. > >> > >> What do you think of the behaviour of the sapply function > below? (I > >> wouldn't put it into R as it is, I'd translate it to C code > >> to avoid the > >> lapply call; but I'd like to get the behaviour right before > >> doing that.) > >> > >> This one checks that the length() and typeof() results are > >> consistent. > >> If the FUN.VALUE has names, those are used (but it doesn't > >> require the > >> names from FUN to match). > > ... > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- > O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B >c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: > (+45) 35327918 > ~~ - (p.dalga...@biostat.ku.dk) FAX: > (+45) 35327907 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply improvements
William Dunlap wrote: ... if (x <= 0) NA else log(x) variety otherwise. Would you only want it to coerce upwards to FUN.VALUES's type? E.g., allow sapply(z, length, FUN.VALUE=numeric(1)) to return a numeric vector but die on sapply(z, function(zi)as.complex(zi[1]), FUN.VALUE=numeric(1)) If the latter doesn't die should it return a complex or a numeric vector? (I'd say it needs to be numeric, but I'd prefer that it died.) I'd say that it should probably die on downwards coercion. Getting a double when an integer is expected, or complex instead of double as you indicate, is a likely user error. If not, then the user can always coerce explicitly inside FUN. Another issue is whether one would want to go beyond the base classes of S (logical, integer, double, complex, character). For other classes, there may be no notion of "up" and "down" in coercion. Then again, sapply was always limited to what unlist() will handle, so e.g. > sapply(1:10,FUN=function(i)Sys.Date()) [1] 14553 14553 14553 14553 14553 14553 14553 14553 14553 14553 as opposed to > structure(rep(14553,10), class="Date") [1] "2009-11-05" "2009-11-05" "2009-11-05" "2009-11-05" "2009-11-05" [6] "2009-11-05" "2009-11-05" "2009-11-05" "2009-11-05" "2009-11-05" -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parse_Rd and/or lazyload problem
Great-- thanks for the info.
For now, hopefully I can get the behaviour I want by sticking a .Call(
'R_lazyLoadDBflush'...) [as per 'detach'] before calling 'lazyLoad'. Seems to
work on my examples, but please let me know if you don't think it'll work
generally-- if not, I could presumably create the files under different names
and then change them.
Is there merit in making 'makeLazyLoadDB' public, just as 'lazyLoad' already
is? It's useful.
Mark
--
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
l...@stat.uiowa.edu wrote:
> Here is a more stripped down variant generates and error on OS X for
> me:
>
> mkEg <- function(tm) list(scrunge = as.POSIXct(tm))
>
> extract <- function(db) {
> e<- new.env()
> lazyLoad(db, e)
> as.list( e)
> }
>
> eg <- mkEg("2009-11-04 12:49:53")
> eg1 <- mkEg("2009-11-04 12:49:28")
>
> tools:::makeLazyLoadDB( eg, '/tmp/ll')
> extract('/tmp/ll') # force; OK
>
> tools:::makeLazyLoadDB( eg1, '/tmp/ll')
> extract('/tmp/ll')
>
> Changing the second set of /tmp/ll makes the symptom go away.
>
> I believe this comes down to unintended use of the lazyload mechanism
> -- in particular it is not intended that a database be rewritten
> after it has been loaded. There is a chaching mechanism for improved
> performance on slow file systems, and I believe what is happening is
> that the new indices are being used to look in the old chached data.
> There might be some merit in having lazyLoad call R_lazyLoadDBflush.
>
> luke
>
> On Tue, 3 Nov 2009, Seth Falcon wrote:
>
>> Hi,
>>
>> On 11/3/09 6:51 PM, mark.braving...@csiro.au wrote:
>>>
>>> file.copy( 'd:/temp/Rdiff.Rd', 'd:/temp/scrunge.Rd') # Rdiff.Rd
>>> from 'tools' package source
>>>
>>> eglist<- list( scrunge=parse_Rd( 'd:/temp/scrunge.Rd'))
>>> tools:::makeLazyLoadDB( eglist, 'd:/temp/ll')
>>> e<- new.env()
>>> lazyLoad( 'd:/temp/ll', e)
>>> as.list( e) # force; OK
>>>
>>> eglist1<- list( scrunge=parse_Rd( 'd:/temp/Rdiff.Rd'))
>>> tools:::makeLazyLoadDB( eglist1, 'd:/temp/ll')
>>> e<- new.env()
>>> lazyLoad( 'd:/temp/ll', e)
>>> as.list( e) # Splat
>>>
>>> It doesn't make any difference which file I process first; the error
>>> comes the second time round.
>>
>> If I adjust this example in terms of paths and run on OS X, I get the
>> following error on the second run:
>>
>>> as.list(e) # Splat
>> Error in as.list.environment(e) : internal error -3 in R_decompress1
>>
>> I haven't looked further yet.
>>
>> + seth
>>
>> __
>> 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
