Re: [Rd] Announcing pqR - a faster version of R
On 13-06-22 2:34 PM, Radford Neal wrote: I have released a new, faster, version of R, which I call pqR (for "pretty quick" R), based on R-2.15.0. Among many other improvements, pqR supports automatic use of multiple cores to perform numerical computations in parallel with other numerical computations, and with the interpretive thread. It also implements a true reference counting scheme to reduce the amount of unnecessary duplication of objects. There are also substantial speed ups in general interpretive overhead, and in particular operations. Readers of r-devel can try out pqR by downloading a source tarball from radfordneal.github.io/pqR (only tested on Linux/Unix so far). The source repository is github.com/radfordneal/pqR - look in the MODS file to see how the changes from R-2.15.0 are organized. The R Core Team may wish to look at the list of bugs fixed in pqR, in the NEWS file, since many of them are present in their current version of R. I will be making a series of posts discussing pqR at my blog, which is at radfordneal.wordpress.com Hi Radford. This is just a public note to say that pqR looks really good; we (R core) are hoping to work with you to incorporate your improvements into base R. I've already started working on the list of R bugs you report in your NEWS file. I hope we can talk privately to clarify some of the entries. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Perplexed with environment
Hi
I migrated from Linux to Mac, but I don't this has anything to do with
it, but I am not sure.
I am writing a small logger package, in which I have a file
aaa.R:
,
| .logData <- new.env()
| assign("loggingThreshold", 10, envir = .logData)
| assign("logToFile", FALSE, envir = .logData)
| assign("logFileName", NULL, envir = .logData)
|
| assign("logToConsole", TRUE, envir = .logData)
| ##
| assign("logHeaderLevel", 0, envir = .logData)
| assign("logHeader", "", envir = .logData)
| assign("logHeaderClock", "", envir = .logData)
| assign("timeFormat", "", envir = .logData)
`
to initialize some logging parameter.
When I load my package, everything looks fine, only that the environment
logger:::.logData is (nearly) empty:
,
| > library(logger)
| > ls(envir=logger:::.logData, all.names=TRUE)
| [1] ".logHeader" ".logHeaderClock" ".logHeaderLevel"
`
I assume I am doing something really basic wrong?
A copy of the package is available at:
https://www.dropbox.com/s/hv6abepcczrljum/logger_0.0-1.tar.gz
Thanks,
Rainer
PS: I am planning to making it available when it is working (again)
--
Rainer M. Krug
email: RMKruggmailcom
pgp_a9eqrII9M.pgp
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] makefile in inst/doc
Section 1.4 of Writing R Extensions is very clear about what not to do with makefiles in the vignettes or inst/doc directory. It provides a BAD EXAMPLE. But it doesn't say (to me) what does work. So what does? As I read the text, it seems that just removing the clean prerequisite from the all target in the BAD EXAMPLE would give something that works. I am referring to the language "Finally, if there is a Makefile and it has a clean: target, make clean is run." This doesn't seem to happen when R CMD build is done, and consequently there are *.aux, *.log, and *.dvi files in the package build that R CMD check --as-cran then complains about. The only thing I can figure out that works is remove the makefile. That does work, but makes it difficult to make the vignettes. Is my only option to remove the Makefile? If so, why discuss makefiles under vignettes at all? -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] How can C++ read the R object written into socket with saveRDS or save
On 25/06/2013 16:52, Rong lI Li wrote: Hi, all, Recently, I met one issue when using socket between R & C++ to transmit R object. Would you pls help give me some suggestions? Many thanks! R-help was really the wrong list: see the posting guide. And multiple posting is really discouraged. But see package 'parallel' which has lots of examples of doing this. [Background]: I create a socket connection between R & C++ binary first, and then, want to use saveRDS() or save() in R to save the object into connection directly. So that the C++ binary can read the object, and send it to another remote R. [What I did so far]: 1. I used socketConnection in R and listen/accept in C++, to establish one blocking socket. 2. I used saveRDS to save the R object into socket directly 3. I want to use "recv()" in C++ to receive the R object. [Issues I met]: I found actually, the saveRDS writes the R object with XDR format. I could It may do ... depending how you call it. You may prefer to serialize() to a raw vector whose size you can find, and transmit that. not know how many bytes are sent into socket, when calling saveRDS to save R object. So in the C++ binary, I could not know exactly how many bytes I should receive from the socket. It is not safe for me, to always use a pre-defined buffer size to read from the socket. Any suggestions for this? Are there safe way for me to read the R object from the socket? I do not do any conversion with the received data, and only need to transfer them into a remote R to do the function execution. = Rong "Jessica", Li (ÀîÈÙ) Platform Symphony TET, CSTL, IBM Systems &Technology Group, Development Tel:86-10-82451010 Email:rong...@cn.ibm.com [[alternative HTML version deleted]] You were asked not to send HTML. __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. -- 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] How can C++ read the R object written into socket with saveRDS or save
On 25 June 2013 at 17:12, Prof Brian Ripley wrote: | On 25/06/2013 16:52, Rong lI Li wrote: | > I found actually, the saveRDS writes the R object with XDR format. I could | | It may do ... depending how you call it. You may prefer to serialize() | to a raw vector whose size you can find, and transmit that. I am not aware of a (simple) library parsing this outside of an R context (and within the R context, I'd always start with Rserve from RForge.net). But you could look into general serialization / translation libraries such as Google Protocol Buffers (see https://developers.google.com/protocol-buffers/) which can also translate into C++, Java, Python plus a host of user-contributed bindings. For R, you will find a package RProtoBuf on CRAN. There are other, related libraries but I have worked only with Protocol Buffers. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] F statistic in add1.lm vs add1.glm
Should the F statistic be the same when using add1() on models created by lm and glm(family=gaussian)? They are in the single-degree-of-freedom case but not in the multiple-degree-of-freedom case. MASS:addterm shows the same discrepancy. It looks like the deviance (==residual sum of squares) gets divided by the number of degrees of freedom for the term twice in add1.glm. Using anova() on the output of lm and glm(family=gaussian) gives the save F statistic as add1.lm gives. > # factor(carb) consumes 5 degrees of freedom, am 1, compare their F values. > fit <- lm(mpg ~ hp, data=mtcars) ; add1(fit, ~ hp + factor(carb) + am, > test="F") Single term additions Model: mpg ~ hp Df Sum of SqRSSAIC F value Pr(>F) 447.67 88.427 factor(carb) 5103.54 344.13 90.009 1.5044 0.2241 am1202.24 245.44 71.194 23.8952 3.46e-05 *** --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 > fit <- glm(mpg ~ hp, data=mtcars) ; add1(fit, ~ hp + factor(carb) + am, > test="F") Single term additions Model: mpg ~ hp Df DevianceAIC F value Pr(>F) 447.67 181.24 factor(carb) 5 344.13 182.82 0.3009 0.9077 am1 245.44 164.01 23.8952 3.46e-05 *** --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stats::convolve documentation enhancement
Hi Hervé, thank you for the link, I like the convolve2() function, it is definitely a more user-friendly version of convolve(). I still believe that convolve() would be worth improving for the R stats package, since it is pretty important in signal processing. I think it would be great to have a better convolution function. Thanks and regards, Michael Am 24.06.2013 20:51, schrieb Hervé Pagès: Hi Michael, There are many issues with stats::convolve() that hopefully one day will be addressed. Full story here: https://stat.ethz.ch/pipermail/r-devel/2007-February/044529.html The user shouldn't have to worry about the lengths of the arguments: convolve() should take care of doing the zero-padding internally so it's always fast. That's what the proposed convolve2() does (in addition to addressing a few other issues). Cheers, H. On 06/23/2013 09:29 AM, Michael Moers wrote: Hi, the function stats::convolve does not mention efficient usage of the underlying FFT algorithm, such as (a) if type="circular", then length(x)=length(y) should have many factors (e.g. length(x) = length(y) = 2^n) (b) if type="open" or "filter", then length(x)+length(y)-1 should have many factors (e.g. length(x)+length(y)-1 = 2^n) In particular the latter may not be obvious to first time users, who may think that stats::convolve is slow, even though it is fast, if applied correctly. Moreover for zero padding, one may apply stats::nextn to (a) length(x) or (b) length(x)+length(y)-1. #Example: #correct usage: x <- rnorm(514289) y <- rnorm(1) #length(x) + length(y) - 1 = 2^19 system.time(convolve(x, y, type="open")) # user system elapsed # 1.170.021.18 #incorrect usage: x <- rnorm(30) y <- rnorm(1) system.time(convolve(x, y, type = "open")) # user system elapsed # 685.310.09 691.79 Thanks and Kind regards, Michael Moers [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] F statistic in add1.lm vs add1.glm
> stats:::add1.glm
function (object, scope, scale = 0, test = c("none", "Rao", "LRT",
"Chisq", "F"), x = NULL, k = 2, ...)
{
Fstat <- function(table, rdf) {
dev <- table$Deviance
df <- table$Df
diff <- pmax(0, (dev[1L] - dev)/df)
Fs <- (diff/df)/(dev/(rdf - df))
Is this where the double division is happening?
diff has df in the denominator, then Fs assignment sees
diff divided by df again. if df is 1, the double division
will go unnoticed.
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of William Dunlap [wdun...@tibco.com]
Sent: June 25, 2013 12:01 PM
To: r-devel@r-project.org
Subject: [Rd] F statistic in add1.lm vs add1.glm
Should the F statistic be the same when using add1() on models created by lm
and glm(family=gaussian)?
They are in the single-degree-of-freedom case but not in the
multiple-degree-of-freedom case.
MASS:addterm shows the same discrepancy. It looks like the deviance
(==residual sum of squares) gets
divided by the number of degrees of freedom for the term twice in add1.glm.
Using anova() on the output
of lm and glm(family=gaussian) gives the save F statistic as add1.lm gives.
> # factor(carb) consumes 5 degrees of freedom, am 1, compare their F values.
> fit <- lm(mpg ~ hp, data=mtcars) ; add1(fit, ~ hp + factor(carb) + am,
> test="F")
Single term additions
Model:
mpg ~ hp
Df Sum of SqRSSAIC F value Pr(>F)
447.67 88.427
factor(carb) 5103.54 344.13 90.009 1.5044 0.2241
am1202.24 245.44 71.194 23.8952 3.46e-05 ***
---
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
> fit <- glm(mpg ~ hp, data=mtcars) ; add1(fit, ~ hp + factor(carb) + am,
> test="F")
Single term additions
Model:
mpg ~ hp
Df DevianceAIC F value Pr(>F)
447.67 181.24
factor(carb) 5 344.13 182.82 0.3009 0.9077
am1 245.44 164.01 23.8952 3.46e-05 ***
---
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
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] stats::convolve documentation enhancement
Hi Michael, On 06/25/2013 12:07 PM, Michael Moers wrote: Hi Hervé, thank you for the link, I like the convolve2() function, it is definitely a more user-friendly version of convolve(). I still believe that convolve() would be worth improving for the R stats package, since it is pretty important in signal processing. I think it would be great to have a better convolution function. I totally agree with that. Cheers, H. Thanks and regards, Michael Am 24.06.2013 20:51, schrieb Hervé Pagès: Hi Michael, There are many issues with stats::convolve() that hopefully one day will be addressed. Full story here: https://stat.ethz.ch/pipermail/r-devel/2007-February/044529.html The user shouldn't have to worry about the lengths of the arguments: convolve() should take care of doing the zero-padding internally so it's always fast. That's what the proposed convolve2() does (in addition to addressing a few other issues). Cheers, H. On 06/23/2013 09:29 AM, Michael Moers wrote: Hi, the function stats::convolve does not mention efficient usage of the underlying FFT algorithm, such as (a) if type="circular", then length(x)=length(y) should have many factors (e.g. length(x) = length(y) = 2^n) (b) if type="open" or "filter", then length(x)+length(y)-1 should have many factors (e.g. length(x)+length(y)-1 = 2^n) In particular the latter may not be obvious to first time users, who may think that stats::convolve is slow, even though it is fast, if applied correctly. Moreover for zero padding, one may apply stats::nextn to (a) length(x) or (b) length(x)+length(y)-1. #Example: #correct usage: x <- rnorm(514289) y <- rnorm(1) #length(x) + length(y) - 1 = 2^19 system.time(convolve(x, y, type="open")) # user system elapsed # 1.170.021.18 #incorrect usage: x <- rnorm(30) y <- rnorm(1) system.time(convolve(x, y, type = "open")) # user system elapsed # 685.310.09 691.79 Thanks and Kind regards, Michael Moers [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perplexed with environment
Hi Rainier,
On 06/25/2013 04:04 AM, Rainer M Krug wrote:
Hi
I migrated from Linux to Mac, but I don't this has anything to do with
it, but I am not sure.
I am writing a small logger package, in which I have a file
aaa.R:
,
| .logData <- new.env()
| assign("loggingThreshold", 10, envir = .logData)
| assign("logToFile", FALSE, envir = .logData)
| assign("logFileName", NULL, envir = .logData)
|
| assign("logToConsole", TRUE, envir = .logData)
| ##
| assign("logHeaderLevel", 0, envir = .logData)
| assign("logHeader", "", envir = .logData)
| assign("logHeaderClock", "", envir = .logData)
| assign("timeFormat", "", envir = .logData)
`
to initialize some logging parameter.
When I load my package, everything looks fine, only that the environment
logger:::.logData is (nearly) empty:
,
| > library(logger)
| > ls(envir=logger:::.logData, all.names=TRUE)
| [1] ".logHeader" ".logHeaderClock" ".logHeaderLevel"
`
I assume I am doing something really basic wrong?
A copy of the package is available at:
https://www.dropbox.com/s/hv6abepcczrljum/logger_0.0-1.tar.gz
Just to let you know that this link doesn't work for me. When trying to
open in a browser, I get the following message:
Nothing Here
The file you're looking for has been deleted or moved.
Cheers,
H.
Thanks,
Rainer
PS: I am planning to making it available when it is working (again)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
