[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)))
{return(1)}
if(((Im(Tot_log_sum))==0)((Re(Tot_log_sum))(log(3/4)/log(2)))((Re(Tot_log_sum))log(5/4)/log(2)))
{return(2)}
if(((Im(Tot_log_sum))==0)((Re(Tot_log_sum))log(5/4)/log(2))((Re(Tot_log_sum))log(7/4)/log(2)))
{return(3)}
if(((Im(Tot_log_sum))==0)((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)==0Re(Tot_log_sum)-2)Re(Tot_log_sum)-.4150375)
return(1)
if(Im(Tot_log_sum)==0Re(Tot_log_sum)-.4150375Re(Tot_log_sum).3219281)
return(2)
if(Im(Tot_log_sum)==0Re(Tot_log_sum).3219281Re(Tot_log_sum).807355)
return(3)
if(Im(Tot_log_sum)==0Re(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)))
{return(1)}
if(((Im(Tot_log_sum))==0)((Re(Tot_log_sum))(log(3/4)/log(2)))((Re(Tot_log_sum))log(5/4)/log(2)))
{return(2)}
if(((Im(Tot_log_sum))==0)((Re(Tot_log_sum))log(5/4)/log(2))((Re(Tot_log_sum))log(7/4)/log(2)))
{return(3)}
if(((Im(Tot_log_sum))==0)((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)))
{return(1)}
if(((Im(Tot_log_sum))==0)((Re(Tot_log_sum))(log(3/4)/log(2)))((Re(Tot_log_sum))log(5/4)/log(2)))
{return(2)}
if(((Im(Tot_log_sum))==0)((Re(Tot_log_sum))log(5/4)/log(2))((Re(Tot_log_sum))log(7/4)/log(2)))
{return(3)}
if(((Im(Tot_log_sum))==0)((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 lig...@statistik.tu-dortmund.de To: Ulrike Grömping gro...@beuth-hochschule.de 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)i0, 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)i0, 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)i0, 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)i0, 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 = FALSE),
dim= c(common.len, length(X)),
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)i0,
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
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 murd...@stats.uwo.ca 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)i0, 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])
}
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)i0, 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)i0, 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)i0, 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)i0, 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
