[Rd] S4 dispatch and S3 "connection" objects
Hello,
I'm trying to get S4 dispatch on S3 "connection" objects.
So I do :
setOldClass( "connection" )
and then :
setGeneric( "bling", function(object) standardGeneric( "bling" ) )
setMethod( "bling", "connection", function(object) cat( "gotcha ",
as.integer(object), "\n" ) )
but I get :
f <- file( "blabla", open = "rb" )
> bling( f )
Error in function (classes, fdef, mtable) :
unable to find an inherited method for function "bling", for
signature "file"
> class( f )
[1] "file" "connection"
Am I supposed to do :
setOldClass( c("file", "connection" ) )
setOldClass( c("url", "connection" ) )
and so on for each potential S3 class, or is there another way.
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/HlX9 : new package : bibtex
|- http://tr.im/Gq7i : ohloh
`- http://tr.im/FtUu : new package : highlight
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Accuracy (PR#14139)
On Mon, Dec 14, 2009 at 06:10:16PM +0100, ber...@lycos.com wrote: > > > pnorm(1.35,0,1) > [1] 0.911492 > > pnorm(1.36,0,1) > [1] 0.913085 > > > options(digits=4) > > > pnorm(1.35,0,1) > [1] 0.9115 > > pnorm(1.36,0,1) > [1] 0.913 rounding error? The technical explanation is as follows. If options(digits=k) is set, then the number of significant digits for printing a single number x is determined as min(k, d), where d is the minimum number of digits, for which the relative error of the printed number is less than 10^-k. If we have x <- 0.913085 y <- 0.913 then the relative error of y as an approximation of x is abs(y - x)/x # [1] 9.3091e-05 Since this is less than 10^-4, the 3 digit precision is chosen for printing x. A safer way of rounding is to use functions round() and signif(). For example, round(x, digits=4) # [1] 0.9131 I do not know the history of the R printing algorithm. It is designed primarily for printing vectors, where the rules are more complicated to achieve a good unified format for all numbers. May be, someone else can say more about it. The above analysis may be obtained by inspecting the R source code. Petr Savicky. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Accuracy (PR#14139)
On Mon, Dec 14, 2009 at 06:10:16PM +0100, ber...@lycos.com wrote: > > > pnorm(1.35,0,1) > [1] 0.911492 > > pnorm(1.36,0,1) > [1] 0.913085 > > > options(digits=4) > > > pnorm(1.35,0,1) > [1] 0.9115 > > pnorm(1.36,0,1) > [1] 0.913 rounding error? The technical explanation is as follows. If options(digits=k) is set, then the number of significant digits for printing a single number x is determined as min(k, d), where d is the minimum number of digits, for which the relative error of the printed number is less than 10^-k. If we have x <- 0.913085 y <- 0.913 then the relative error of y as an approximation of x is abs(y - x)/x # [1] 9.3091e-05 Since this is less than 10^-4, the 3 digit precision is chosen for printing x. A safer way of rounding is to use functions round() and signif(). For example, round(x, digits=4) # [1] 0.9131 I do not know the history of the R printing algorithm. It is designed primarily for printing vectors, where the rules are more complicated to achieve a good unified format for all numbers. May be, someone else can say more about it. The above analysis may be obtained by inspecting the R source code. Petr Savicky. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New version weighted mean differs from the old one (PR#14142)
This was PR#14032. Fixed in R.10.1. On Mon, 14 Dec 2009, huh...@dreamwiz.com wrote: Full_Name: Myung-Hoe Huh Version: 2.10 OS: Windows Submission from: (NULL) (116.120.84.194) New Version (2.10.0) weighted mean produces unreasonable result: see below. wt <- c(5, 5, 4, 1)/15 x <- c(3.7,3.3,3.5,2.8) x[4] <- NA (xm <- weighted.mean(x,wt,na.rm=T)) Outcome is (xm <- weighted.mean(x,wt,na.rm=T)) [1] 3.27 The number is obtained by treating x[4] <- 0 I think the old version(2.8.0)'s weighte mean is more reasonable. The old output was (xm <- weighted.mean(x,wt,na.rm=T)) [1] 3.5 The number si obtained ignoring the x[4], which is NA. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:cbe...@tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.data.frame requires a lot of memory (PR#14140)
On Dec 14, 2009, at 12:45 , rfa...@tzi.de wrote:
Full_Name: Raimar Falke
Version: R version 2.10.0 (2009-10-26)
OS: Linux 2.6.27-16-generic #1 SMP Tue Dec 1 19:26:23 UTC 2009
x86_64 GNU/Linux
Submission from: (NULL) (134.102.222.56)
The construction of a data frame in the way shown below requires
much more memory than expected. If we assume a cell value takes 8
bytes
the total amount of the data is 128mb. However the process takes about
920mb and not the expected 256mb (two times the data set).
With the real data sets (~35000 observations with ~33000 attributes)
the
conversion to a data frame requires has to be killed at with 60gb of
memory usage while it should only require 17.6gb (2*8.8gb).
dfn <- rep(list(rep(0, 4096)), 4096)
test <- as.data.frame.list(dfn)
I also tried the incremental construction of the
data-frame: df$colN <- dataForColN. While I currently can't say much
about the memory usage, it takes a looong time.
After the construction the saved-and-loaded data-frame has the
expected size.
What is the recommended way to construct larger data-frames?
Please use R-help for questions, and not the bug tracking system!
There are few issues with your example - mainly because is has no row
names and no column names so R will try to create them from the
expression which is inherently slow and memory-consuming. So first,
make sure you set the names on the list, e.g.:
names(dfn) <- paste("V",seq.int(length(dfn)),sep='')
That will reduce the overhead due to column names. Then what
as.data.frame does is to simply call data.frame on the elements of the
list. That ensures that all is right, but if you know for sure that
your list is valid (correct lengths, valid names, no need for row
names etc.) then you can simply assert that it is a data frame:
class(dfn)<-"data.frame"
row.names(dfn)<-NULL
You'll still need double the memory because the object needs to be
copied for the attribute modifications, but that's as low as it get --
although in your exact example there is an even more efficient way:
dfn <- rep(data.frame(X=rep(0, 4096)), 4096)
dfn <- do.call("cbind", dfn)
it uses only a fraction more memory than the size of the entire
object, but that's for entirely different reasons :). No, it's not
good in general :P
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dumpMethod/getMethod on methods in packages
There seems to be something wrong with dumpMethod when called on methods
defined in packages (possibly with namespaces). This may be caused by a
possible bug in getMethod.
(see below for a full copy/paste without comments)
First
library(Matrix)
Now compare
dumpMethod("rowSums", "ngCMatrix", file = "") ## Nothing
to
getMethod("rowSums", "ngCMatrix") ## The method definition
Further inspection suggests that it is related to the where argument to
dumpMethod, the default being where = topenv(parent.frame()) which evaluates
(in this usecase) to .GlobalEnv. I find it interesting to compare
findMethod("rowSums", "ngCMatrix", where = .GlobalEnv) ## Finds the method
in the Matrix package
to
getMethod("rowSums", "ngCMatrix", where = .GlobalEnv) ## Does not find
anything
It seems to me that getMethod is wrong when it does not find anything in the
global environment.
Tested in R-2.10-patched (r50736) and R-devel (r50736)
dumpMethod works fine with example(dumpMethod) where a method gets defined in
the global environment. My usecase was trying to dump a method from a
namespace I had edited with trace(..., edit = TRUE)
Kasper
All 5 lines for copy and paste:
library(Matrix)
dumpMethod("rowSums", "ngCMatrix", file = "")
getMethod("rowSums", "ngCMatrix")
findMethod("rowSums", "ngCMatrix", where = .GlobalEnv)
getMethod("rowSums", "ngCMatrix", where = .GlobalEnv)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rd cross-references ... WARNING in R-2.10.*
I have observed a difference in behavior of R CMD check in older R vs R-2.10.x on windows. * using R version 2.10.0 (2009-10-26) * using R version 2.10.1 RC (2009-12-14 r50718) 2.10 seems to be looking on the internet for crossreferenced packages. I am not sure why it is looking. The string is not in any of the Rd files. I think it is not finding any CRAN sites because I am currently behind a firewall. I have attempted several variations of R --internet2 CMD check --no-examples --no-latex packagename and no position that I placed the keyword "--internet2" was valid. * checking Rd metadata ... OK * checking Rd cross-references ... WARNING Warning: unable to access index for repository http://cran.r-project.org/src/con trib Warning: unable to access index for repository http://www.omegahat.org/R/src/con trib Warning: unable to access index for repository http://www.bioconductor.org/packa ges/2.5/bioc/src/contrib Warning: unable to access index for repository http://www.bioconductor.org/packa ges/2.5/data/annotation/src/contrib Warning: unable to access index for repository http://www.bioconductor.org/packa ges/2.5/data/experiment/src/contrib Unknown package(s) '' in Rd xrefs * checking for missing documentation entries ... WARNING By comparison * using R version 2.8.0 (2008-10-20) * checking Rd cross-references ... OK * checking for missing documentation entries ... WARNING If my diagnosis looks correct, can you suggest what is triggering the search on the internet? Can you give a more specific warning message? Is there a way to force internet2 in the R CMD check setting? Thanks Rich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.data.frame requires a lot of memory (PR#14140)
Full_Name: Raimar Falke Version: R version 2.10.0 (2009-10-26) OS: Linux 2.6.27-16-generic #1 SMP Tue Dec 1 19:26:23 UTC 2009 x86_64 GNU/Linux Submission from: (NULL) (134.102.222.56) The construction of a data frame in the way shown below requires much more memory than expected. If we assume a cell value takes 8 bytes the total amount of the data is 128mb. However the process takes about 920mb and not the expected 256mb (two times the data set). With the real data sets (~35000 observations with ~33000 attributes) the conversion to a data frame requires has to be killed at with 60gb of memory usage while it should only require 17.6gb (2*8.8gb). dfn <- rep(list(rep(0, 4096)), 4096) test <- as.data.frame.list(dfn) I also tried the incremental construction of the data-frame: df$colN <- dataForColN. While I currently can't say much about the memory usage, it takes a looong time. After the construction the saved-and-loaded data-frame has the expected size. What is the recommended way to construct larger data-frames? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Online help for text() wrong for 'pos' argument. (PR#14136)
This is a multi-part message in MIME format. --000902010602030404010803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Please find bug report attached. Thanks Matthew -- Matthew Gillman Team 105: Variation Informatics Wellcome Trust Sanger Institute, Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SA, UK Tel: 01223 834244 Ext. 4922 -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. --000902010602030404010803 Content-Type: text/plain; name="R.bug.report" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="R.bug.report" Hello I believe the help for the 'text' function (which places text on graphs) is wrong, specifically for the 'pos' variable. I did some tests to place some text, e.g. text(2000, -3, "This is a test at (2000, -3)", cex = 0.5, srt=90, pos=4) With no pos, the (vertical) text was centred at the specified co-ordinates. When pos=1, it was to the right pos=2 -> below pos=3 -> left pos=4 -> above and to the right. This disagrees with what the online help says: "Values of '1', '2', '3' and '4', respectively indicate positions below, to the left of, above and to the right of the specified coordinates." Thanks Matthew Gillman mg10 _at_ sanger _dot_ ac _dot_ uk --please do not edit the information below-- Version: platform = x86_64-unknown-linux-gnu arch = x86_64 os = linux-gnu system = x86_64, linux-gnu status = major = 2 minor = 9.0 year = 2009 month = 04 day = 17 svn rev = 48333 language = R version.string = R version 2.9.0 (2009-04-17) Locale: C Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base > sessionInfo() R version 2.9.0 (2009-04-17) x86_64-unknown-linux-gnu locale: C attached base packages: [1] stats graphics grDevices utils datasets methods base > --000902010602030404010803-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] New version weighted mean differs from the old one (PR#14142)
Full_Name: Myung-Hoe Huh Version: 2.10 OS: Windows Submission from: (NULL) (116.120.84.194) New Version (2.10.0) weighted mean produces unreasonable result: see below. wt <- c(5, 5, 4, 1)/15 x <- c(3.7,3.3,3.5,2.8) x[4] <- NA (xm <- weighted.mean(x,wt,na.rm=T)) Outcome is > (xm <- weighted.mean(x,wt,na.rm=T)) [1] 3.27 The number is obtained by treating x[4] <- 0 I think the old version(2.8.0)'s weighte mean is more reasonable. The old output was > (xm <- weighted.mean(x,wt,na.rm=T)) [1] 3.5 The number si obtained ignoring the x[4], which is NA. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Accuracy (PR#14139)
Full_Name: Bernd Schuster Version: 2.10.0 OS: Windows Vista Submission from: (NULL) (91.115.36.35) > pnorm(1.35,0,1) [1] 0.911492 > pnorm(1.36,0,1) [1] 0.913085 > options(digits=4) > pnorm(1.35,0,1) [1] 0.9115 > pnorm(1.36,0,1) [1] 0.913 rounding error? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check may not detect a code/documentation mismatch
On Mon, Dec 14, 2009 at 09:24:12AM +0100, Kurt Hornik wrote:
> > Peter Dalgaard writes:
[...]
> > Hmm, looks more like a thinko in this code inside codoc():
>
> > functions_in_code <- Filter(function(f) {
> > f <- get(f, envir = code_env)
> > is.function(f) && (length(formals(f)) > 0L)
> > }, objects_in_code)
>
> > which, further down the line, causes functions with no formal arguments
> > to be skipped when compared to the usage section.
>
> > Browse[2]>
> > debug: ind <- (!functions %in% functions_to_be_ignored & functions %in%
> > functions_in_code)
> > Browse[2]> functions
> > [1] "testCoreClass""testCoreAttrEval" "testCoreReg"
> > "testCoreNA"
> > Browse[2]>
> > debug: bad_functions <- mapply(functions[ind], exprs[ind], FUN =
> > function(x,
> > y) check_codoc(x, as.pairlist(as.alist.call(y[-1L]))), SIMPLIFY =
> > FALSE)
> > Browse[2]> ind
> > [1] TRUE TRUE TRUE FALSE
>
> > I.e. testCoreNA is never tested by check_codoc. There may of course be
> > a rationale for this, but it escapes me...
>
> Well, I am sure I had good reasons when I wrote the code many years ago,
> but of course I no longer recall what they were.
>
> Did you try the effect of removing the length(formals(f)) test?
I understand this as the question, what is the influence of the following patch
(indented by two spaces).
diff --minimal -U 3 -r R-devel_2009-12-13/src/library/tools/R/QC.R
R-devel_length_formals/src/library/tools/R/QC.R
--- R-devel_2009-12-13/src/library/tools/R/QC.R 2009-10-27
02:59:10.0 +0100
+++ R-devel_length_formals/src/library/tools/R/QC.R 2009-12-14
18:45:55.0 +0100
@@ -398,7 +398,7 @@
functions_in_code <-
Filter(function(f) {
f <- get(f, envir = code_env)
- is.function(f) && (length(formals(f)) > 0L)
+ is.function(f)
},
objects_in_code)
## Sourcing all R code files in the package is a problem for base,
Since i do not know this part of R code, i simply applied the patch to the
current R-devel and run "make" and "make check" (both OK) and compared
the output of
R CMD check XML_2.6-0.tar.gz
R CMD check randomForest_4.5-33.tar.gz
R CMD check tree_1.0-27.tar.gz
R CMD check survival_2.35-7.tar.gz
with R being both original R-devel and the modified one. The results were
identical
in all four cases (empty diff) on two Linux machines (CentOS and openSUSE).
On the other hand, for the package
http://www.cs.cas.cz/~savicky/R-devel/something_0.0.0.tar.gz
which demonstrates the problem, the modified R detected the code/doc mismatch.
The diff of the two outputs of R CMD check was
[savi...@uivtx test]$ diff original modified
35c35,42
< * checking for code/documentation mismatches ... OK
---
> * checking for code/documentation mismatches ... WARNING
> Codoc mismatches from documentation object 'testCore':
> testCoreNA
> Code: function()
> Docs: function(verbose = 0)
> Argument names in docs not in code:
> verbose
>
39a47,50
> WARNING: There was 1 warning, see
> /home/savicky/tmp/test/something.Rcheck/00check.log
> for details
>
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
[my message below is a bit off-topic]
2009/12/14 Paul Murrell :
> I have thought a bit about drawing the same image multiple times (more in
> the context of using a bitmap for a plotting symbol). I imagine something
> like being able to "add" a raster image to a device and then simply "refer"
> to that image (e.g., by name) is needed.
That would be nice.
I first thought that this new rasterGrob would be a good way to
implement some kind of filling pattern for grid graphics, but after
some more testing I was surprised to see that a similar approach with
vector patterns could result in more efficient, better output. Of
course raster filling patterns could still be nice to have for fancy
images or gradients.
One thing that worries me with the approach I've taken below is that
the grob is not vectorized. In particular, if one was to use it as a
building block for histograms (as in base graphics' density parameter)
each rectangle would have to be drawn in sequence. I can of course
Vectorize() this grob into a new one (gTree) but I haven't seen any
examples like this before. Does this sound reasonable? (argument
explosion might be another problem...)
Best regards,
baptiste
Below is the gist of my experiments (the first part is not related to
grid.raster and runs in current R).
library(grid)
## vector patterns
source("http://gridextra.googlecode.com/svn/trunk/R/vpattern.r";)
dev.new()
grid.newpage()
grid.vpattern(x=0.2, width=unit(3,"cm"), height=unit(0.5,"npc"),
motif="points", motif.params=list(pch=22,
gp=gpar(cex=0.8, lwd=5, col="grey90",
fill="grey95")), clip=T)
grid.vpattern(x=0.5, width=unit(0.3,"npc"), height=unit(0.5,"npc"),
motif="segments", motif.params=list(angle=45,
gp=gpar(lty=2, col="grey", lwd=2.4)))
grid.vpattern(x=0.5, y=0.9, width=unit(0.5,"npc"), height=unit(1,"cm"),
motif="points", motif.params=list(pch="+"), clip=F,
pattern.offset=c(1, 0.5))
grid.vpattern(x=0.8, width=unit(0.2,"npc"), height=unit(0.2,"npc"),
motif="grid", motif.params=list(angle=45,
gp=gpar(lwd=10, col="grey90")), clip=T,
pattern.offset=c(-1, 0.5))
grid.vpattern(x=0.5, y=0.1, width=unit(0.9,"npc"), height=unit(0.1,"npc"),
motif="grid", motif.params=list(angle=30, gp=gpar(col="red")),
gp=gpar(alpha=0.1, fill="red"))
## raster patterns
source("http://gridextra.googlecode.com/svn/trunk/R/rpattern.r";)
## a raster motif
plus <- function(..., width=5, height=5){
x11(width=width/25.4, height=height/25.4)
grid.points(x=unit(0.5, "npc"), y=unit(0.5, "npc"),
pch=3, size=unit(2, "mm"), gp=gpar(), ...)
m <- grid.cap()
dev.off()
invisible(m)
}
.plus <- plus()
g1 <- rpatternGrob(x=0.5, y=0.4, width=unit(3.7, "cm"),
height=unit(0.4, "npc"),
clip=TRUE, motif=.plus)
dev.new()
grid.draw(g1)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] qpois errors for degenerate distribution (PR#14135)
> "JL" == Jerry Lewis > on Mon, 14 Dec 2009 11:15:10 +0100 (CET) writes: JL> Full_Name: Jerry W. Lewis Version: 2.10.0 OS: XP JL> Professional Submission from: (NULL) (96.237.55.233) JL> For a degenerate Poisson distribution (lambda==0), JL> qpois(p,0,lower.tail) should return 0 for any valid p, JL> but qpois(1,0) and qpois(0,0,F) incorrectly return Inf. It's very much a borderline case. But you are right. This will be fixed in the next versions of R, but not yet in R 2.10.1 released a few hours ago ... ;-) Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ar.ols(): negative determinant problem
Hi,
I was pointed by a request on R-help to the following problem with
ar.ols():
R> set.seed(1)
R> x <- matrix(rnorm(4 * 2), ncol = 2)
R> ar.ols(x, order.max = 1, aic = FALSE, demean = FALSE)
Error in if ((dimension < 1) | (dimension > n)) stop("wrong embedding
dimension") :
argument is of length zero
In addition: Warning message:
In log(det(varE[[m - order.min + 1L]])) : NaNs produced
This happens on my 32-bit Debian (i686-pc-linux-gnu), both in R-release
and R-devel. The source is a numerical instability in the computations of
the error variance and subsequent AIC.
YH <- A[[m - order.min + 1L]] %*% t(X)
E <- (Y - YH)
varE[[m - order.min + 1L]] <- E %*% t(E)/N
[...]
aic[m - order.min + 1L] <- n.used * log(det(varE[[m -
order.min + 1L]])) + 2 * nser * (nser * m + intercept)
varE is the cross-product of the errors E and should be positive-definite
but here det(varE[[1]]) is -6.920697e-17 (on my machine) and thus taking
logs gives NaN yielding an aic of NaN for which the minimum cannot be
determined.
Of course, it does not make much sense to fit such a VAR model but either
a more meaningful error or a workaround would be useful. For example one
could take
log(max(0, det(varE[[m - order.min + 1L]])))
to avoid the negative determinant problem.
Best,
Z
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R on Windows crashes when using certain characters in strings (PR#14137)
On 10/12/2009 4:20 AM, k...@huftis.org wrote: > Full_Name: Karl Ove Hufthammer > Version: 2.10.0 > OS: Windows XP > Submission from: (NULL) (93.124.134.66) > > > I have found a rather strange bug in R 2.10.0 on Windows, where the choice of > characters used in a string make R crash (i.e., Windows shows a dialogue > saying > that the application has a problem, and must be closed). This was related to encoding changes. It likely appeared Windows-specific because Windows uses a different default encoding than most Linux systems. I believe it is fixed now in R-devel, and it will soon make it into 2.10.1-patched, but it came too late to make it into today's release. I believe PR#14114 was the same issue and is also fixed, but I did less testing of it. I'd appreciate it if those who saw either bug in real code test the patches. They should be in today's tarball of R-devel, and did make it into the Windows binary build of R-devel this morning. Duncan > > I can reproduce the bug on two separate systems running Windows XP, and with > both R 2.10.0 and the latest R.2.10.1 RC. > > The following commands trigger the crash for me: > > n=1e5 > k=10 > x=sample(k,n,replace=TRUE) > y=sample(k,n,replace=TRUE) > xy=paste(x,y,sep=" × ") > z=sample(n) > d=data.frame(xy,z) > > The last step takes very long time, and R crashes before it's finished. Note > that if I reduce n, the problem disappears. Also, if I change the × (a > multiplication symbol) to a x (a letter), the problem also disappears (and the > last command takes almost no time to run). > > I originally discovered this (or a related?) bug while using 'unique' on a > data > frame similar to the 'd' data frame defined above, where R would often, but > not > always, crash. > >> sessionInfo() > R version 2.10.0 (2009-10-26) > i386-pc-mingw32 > > locale: > [1] LC_COLLATE=Norwegian-Nynorsk_Norway.1252 > [2] LC_CTYPE=Norwegian-Nynorsk_Norway.1252 > [3] LC_MONETARY=Norwegian-Nynorsk_Norway.1252 > [4] LC_NUMERIC=C > [5] LC_TIME=Norwegian-Nynorsk_Norway.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R on Windows crashes when using certain characters in strings in data frames (PR#14125)
On 10/12/2009 4:20 AM, k...@huftis.org wrote: Full_Name: Karl Ove Hufthammer Version: 2.10.0 OS: Windows XP Submission from: (NULL) (93.124.134.66) I have found a rather strange bug in R 2.10.0 on Windows, where the choice of characters used in a string make R crash (i.e., Windows shows a dialogue saying that the application has a problem, and must be closed). This was related to encoding changes. It likely appeared Windows-specific because Windows uses a different default encoding than most Linux systems. I believe it is fixed now in R-devel, and it will soon make it into 2.10.1-patched, but it came too late to make it into today's release. I believe PR#14114 was the same issue and is also fixed, but I did less testing of it. I'd appreciate it if those who saw either bug in real code test the patches. They should be in today's tarball of R-devel, and did make it into the Windows binary build of R-devel this morning. Duncan I can reproduce the bug on two separate systems running Windows XP, and with both R 2.10.0 and the latest R.2.10.1 RC. The following commands trigger the crash for me: n=1e5 k=10 x=sample(k,n,replace=TRUE) y=sample(k,n,replace=TRUE) xy=paste(x,y,sep=" × ") z=sample(n) d=data.frame(xy,z) The last step takes very long time, and R crashes before it's finished. Note that if I reduce n, the problem disappears. Also, if I change the × (a multiplication symbol) to a x (a letter), the problem also disappears (and the last command takes almost no time to run). I originally discovered this (or a related?) bug while using 'unique' on a data frame similar to the 'd' data frame defined above, where R would often, but not always, crash. sessionInfo() R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=Norwegian-Nynorsk_Norway.1252 [2] LC_CTYPE=Norwegian-Nynorsk_Norway.1252 [3] LC_MONETARY=Norwegian-Nynorsk_Norway.1252 [4] LC_NUMERIC=C [5] LC_TIME=Norwegian-Nynorsk_Norway.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ 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] qpois errors for degenerate distribution (PR#14135)
Full_Name: Jerry W. Lewis Version: 2.10.0 OS: XP Professional Submission from: (NULL) (96.237.55.233) For a degenerate Poisson distribution (lambda==0), qpois(p,0,lower.tail) should return 0 for any valid p, but qpois(1,0) and qpois(0,0,F) incorrectly return Inf. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check may not detect a code/documentation mismatch
Kurt Hornik wrote:
>> Peter Dalgaard writes:
>
>> Petr Savicky wrote:
>>> For the package at
>>> http://www.cs.cas.cz/~savicky/R-devel/something_0.0.0.tar.gz
>>> which is a minor part of some other package only to demonstrate the
>>> problem, i get (under R version 2.11.0 Under development 2009-12-12 r50714
>>> and also under R-2.9.2, openSUSE 11.1 (x86_64) and CentOS release 5.2)
>>>
>>> R CMD check something_0.0.0.tar.gz
>>>
>>> ...
>>> * checking Rd files ... OK
>>> * checking Rd metadata ... OK
>>> * checking Rd cross-references ... OK
>>> * checking for missing documentation entries ... OK
>>> * checking for code/documentation mismatches ... OK
>>> * checking Rd \usage sections ... OK
>>> * checking examples ... NONE
>>> * checking PDF version of manual ... OK
>>>
>>> although the package code contains
>>>
>>> testCoreNA <- function()
>>>
>>> and the documentation contains
>>>
>>> \usage{
>>> testCoreClass(verbose=0)
>>> testCoreAttrEval(verbose=0)
>>> testCoreReg(verbose=0)
>>> testCoreNA(verbose=0)
>>> }
>>>
>>> There is a mismatch between code and documentation of testCoreNA(). Is the
>>> problem caused by having four entries in \usage{} section?
>
>> Hmm, looks more like a thinko in this code inside codoc():
>
>> functions_in_code <- Filter(function(f) {
>> f <- get(f, envir = code_env)
>> is.function(f) && (length(formals(f)) > 0L)
>> }, objects_in_code)
>
>> which, further down the line, causes functions with no formal arguments
>> to be skipped when compared to the usage section.
>
>> Browse[2]>
>> debug: ind <- (!functions %in% functions_to_be_ignored & functions %in%
>> functions_in_code)
>> Browse[2]> functions
>> [1] "testCoreClass""testCoreAttrEval" "testCoreReg"
>> "testCoreNA"
>> Browse[2]>
>> debug: bad_functions <- mapply(functions[ind], exprs[ind], FUN =
>> function(x,
>> y) check_codoc(x, as.pairlist(as.alist.call(y[-1L]))), SIMPLIFY =
>> FALSE)
>> Browse[2]> ind
>> [1] TRUE TRUE TRUE FALSE
>
>> I.e. testCoreNA is never tested by check_codoc. There may of course be
>> a rationale for this, but it escapes me...
>
> Well, I am sure I had good reasons when I wrote the code many years ago,
> but of course I no longer recall what they were.
>
> Did you try the effect of removing the length(formals(f)) test?
Not yet. Priorities
-p
--
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] Calendar week ISO (PR#14132)
Why are you reporting a POSIX standard feature missing in your OS as a
bug in R? (One that is even documented on the help page.)
On more comprehensive OSes you can use the %V format of strftime.
You could compile a replacement for Windows' strftime and link it into
your build of R, as we have done for so many other Windows lacunae.
Then in your example use as.integer(strftime(tmp.d, "%V"))
On Fri, 11 Dec 2009, samand...@gmx.ch wrote:
Hi there
=20
I use Gnu R sometimes at work.=20
=20
Unfortunately we use Windows and R has problems with getting the calendar
That is simply false: R is not responsible for the lack of standards
compliance of Windows, and filing a bug report with Microsoft would be
much more appropriate.
week number with the first week as the one which has at least 4 days. A
colleague told me that he has the same problem.=20
=20
Below you can see what I use now, for finding the right week.=20
=20
=20
Kind regards,=20
Samuel Andreas Meichtry
=20
=20
#Excel-Funktion
#=3DK=DCRZEN((A3-DATUM(JAHR(A3+3-REST(A3-2;7));1;REST(A3-2;7)-9))/7)
=20
=20
#R-Funktion
KW<-function(x){=20=20=20=20
return(floor(
as.numeric((x-(as.Date(ISOdate(
=20
as.numeric(format(as.Date(as.numeric(x)+3+25569-2-(as.numeric(x)-2+25569)%%7
,origin=3D"1900-01-01"),"%Y")),1,1)
)+((as.numeric(x)-2+25569)%%7-9)-1))/7)))=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20
}
=20
tmp.d <- seq(as.Date("1970-01-01"),as.Date("2009-01-01"),"days")
df<-data.frame(TimeStamp=3Dtmp.d,KW=3DKW(tmp.d))
=20
[[alternative HTML version deleted]]
__
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] R CMD check may not detect a code/documentation mismatch
> Peter Dalgaard writes:
> Petr Savicky wrote:
>> For the package at
>> http://www.cs.cas.cz/~savicky/R-devel/something_0.0.0.tar.gz
>> which is a minor part of some other package only to demonstrate the
>> problem, i get (under R version 2.11.0 Under development 2009-12-12 r50714
>> and also under R-2.9.2, openSUSE 11.1 (x86_64) and CentOS release 5.2)
>>
>> R CMD check something_0.0.0.tar.gz
>>
>> ...
>> * checking Rd files ... OK
>> * checking Rd metadata ... OK
>> * checking Rd cross-references ... OK
>> * checking for missing documentation entries ... OK
>> * checking for code/documentation mismatches ... OK
>> * checking Rd \usage sections ... OK
>> * checking examples ... NONE
>> * checking PDF version of manual ... OK
>>
>> although the package code contains
>>
>> testCoreNA <- function()
>>
>> and the documentation contains
>>
>> \usage{
>> testCoreClass(verbose=0)
>> testCoreAttrEval(verbose=0)
>> testCoreReg(verbose=0)
>> testCoreNA(verbose=0)
>> }
>>
>> There is a mismatch between code and documentation of testCoreNA(). Is the
>> problem caused by having four entries in \usage{} section?
> Hmm, looks more like a thinko in this code inside codoc():
> functions_in_code <- Filter(function(f) {
> f <- get(f, envir = code_env)
> is.function(f) && (length(formals(f)) > 0L)
> }, objects_in_code)
> which, further down the line, causes functions with no formal arguments
> to be skipped when compared to the usage section.
> Browse[2]>
> debug: ind <- (!functions %in% functions_to_be_ignored & functions %in%
> functions_in_code)
> Browse[2]> functions
> [1] "testCoreClass""testCoreAttrEval" "testCoreReg"
> "testCoreNA"
> Browse[2]>
> debug: bad_functions <- mapply(functions[ind], exprs[ind], FUN =
> function(x,
> y) check_codoc(x, as.pairlist(as.alist.call(y[-1L]))), SIMPLIFY =
> FALSE)
> Browse[2]> ind
> [1] TRUE TRUE TRUE FALSE
> I.e. testCoreNA is never tested by check_codoc. There may of course be
> a rationale for this, but it escapes me...
Well, I am sure I had good reasons when I wrote the code many years ago,
but of course I no longer recall what they were.
Did you try the effect of removing the length(formals(f)) test?
-k
> --
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
