Re: [Rd] Fixing ambiguous corrections and reattempting to submit package to R
On 01/03/2015 10:09 PM, Luck Buttered wrote: > Hello: > > I recently submitted a package to R using devtools:release(). > > I received no errors, warnings, or notes in R CMD check. > > However, I received two notes in devtools::release(): > > 1) checking CRAN incoming feasibility ... NOTE > 2) checking package dependencies ... NOTE >No repository set, so cyclic dependency check skipped > > After I submitted the package, I was told to fix two things, of which I am > unsure: > > 1) The Title field should be in title case, current version then in title case > 2) checking CRAN incoming feasibility ... NOTE > > For the first issue, I changed my title field in the DESCRIPTION file to be > title case, as it had been all lower-case. However, I do not know if that > is a sufficient change, given their response wording "The Title field > should be in title case, current version then in title case". If all I need > to do is change my title field to title case, I would imagine their > response would simply be "The Title field should be in title case". Perhaps they made an error editing. It happens. > > When I did research on the second issue (from websites like these): > 1) > http://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer > 2) http://grokbase.com/t/r/r-help/129ncmtvga/r-new-submission-to-cran-note > > The first website tells me to ignore the note, with a reference to CRAN > member Uwe Ligges, while the second website tells me to send an e-mail to > cran at r-project.org, and state that I agree to the CRAN repository > policies. > > So, would it be correct (of good etiquette) for me to simply change my > title field in the DESCRIPTION field to title case, rerun > devtools::release(), and then send an e-mail to cran at r-project.org, and > state that I agree to the CRAN repository policies (which I did not do the > first time I submitted)? The people at CRAN prefer that you use their web page for submissions. (The URL is listed in their policy document.) It is less work for them, and believe me, they do a lot of work. > > Thank you for any advice. > > > Below is the format of my DESCRIPTION file: > > > Package: packageName > > Version: 0.1.0 > > Title: Title in Title Case that does not end in Period > > Description: Statement about methods available. > > Author: Author One, Author Two > > Maintainer: Author One Those don't look like real names. Since you are claiming copyright on the work you're submitting, you should include real names, and a real email address in the Maintainer field to respond to queries about it. See the CRAN policy document on the CRAN website. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-devel does not update the C++ returned variables
Hi,
Within my R code, I am using a C++ function as below:
overlaps <- matrix(0, nrow=B, ncol=length(N))
overlaps.P <- matrix(0, nrow=B, ncol=length(N))
.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N),
ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE)
the function "speedUp", is supposed to update matrices overlaps and
overlaps.P and it works with official R versions.
However, using the same code in R-devel, it does not update matrices and
they remain all zero without returning any errors.
But, if I store the return values from C function in a variable lets say
"test" as follows:
test <-.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N),
length(N),
ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE)
then the corresponding element of test to matrix "overlaps"
(test[["overlaps"]]) again has the updated values (correct non-zero values)
though the overlaps matrix itself is still empty.
I mean in official R, the "overlaps" matrix is updated after calling the
function but not in R-devel. Also it works in both environment and return
correct values to variable "test" in R-devel as well.
Did you face any similar problem so that R-devel does not update the
variable returned by C++?
Thanks for the help.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel does not update the C++ returned variables
On 02/03/2015 3:50 AM, sarah manderni wrote:
> Hi,
>
> Within my R code, I am using a C++ function as below:
>
> overlaps <- matrix(0, nrow=B, ncol=length(N))
> overlaps.P <- matrix(0, nrow=B, ncol=length(N))
>
>.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N),
>ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE)
>
>
> the function "speedUp", is supposed to update matrices overlaps and
> overlaps.P and it works with official R versions.
> However, using the same code in R-devel, it does not update matrices and
> they remain all zero without returning any errors.
See the NEWS: DUP=FALSE is now ignored. It led to too many bugs. Use
the .Call interface if duplication causes problems.
Duncan Murdoch
> But, if I store the return values from C function in a variable lets say
> "test" as follows:
>
> test <-.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N),
> length(N),
>ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE)
>
> then the corresponding element of test to matrix "overlaps"
> (test[["overlaps"]]) again has the updated values (correct non-zero values)
> though the overlaps matrix itself is still empty.
>
> I mean in official R, the "overlaps" matrix is updated after calling the
> function but not in R-devel. Also it works in both environment and return
> correct values to variable "test" in R-devel as well.
> Did you face any similar problem so that R-devel does not update the
> variable returned by C++?
>
> Thanks for the help.
>
> [[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] R-devel does not update the C++ returned variables
On 02/03/2015 8:46 AM, sarah manderni wrote:
Thanks! I went through the online posts which supports the power of
.Call over .C. But my probably naive question is why does this work
for my code with R but not R-devel?
Because of the change mentioned in the NEWS file.
And another question is related to using .Call. Based on the manual
page, I do not need to change the function parameters when using
.Call. So I can run like this:
.Call("sppedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N),
ssq[i], i, as.integer(B), overlaps, overlaps.P)
But I am receiving the memory(?) related error:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Now that I am running the code using .Call.
Code using .Call is quite different from code using .C. My guess would
be that you didn't get all the details right.
I generally recommend that people use Rcpp, which hides a lot of the
details. It will generate your .Call calls for you, and generate the
C++ code that receives them; you just need to think about the real
problem, not the interface. It has its own learning curve, but I think
it is easier than using the low-level code that you need to work with .Call.
Duncan Murdoch
Thanks.
On Mon, Mar 2, 2015 at 2:01 PM, Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
On 02/03/2015 3:50 AM, sarah manderni wrote:
> Hi,
>
> Within my R code, I am using a C++ function as below:
>
> overlaps <- matrix(0, nrow=B, ncol=length(N))
> overlaps.P <- matrix(0, nrow=B, ncol=length(N))
>
>.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N),
length(N),
>ssq[i], i, as.integer(B), overlaps, overlaps.P,
DUP=FALSE)
>
>
> the function "speedUp", is supposed to update matrices overlaps and
> overlaps.P and it works with official R versions.
> However, using the same code in R-devel, it does not update
matrices and
> they remain all zero without returning any errors.
See the NEWS: DUP=FALSE is now ignored. It led to too many
bugs. Use
the .Call interface if duplication causes problems.
Duncan Murdoch
> But, if I store the return values from C function in a variable
lets say
> "test" as follows:
>
> test <-.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N),
> length(N),
>ssq[i], i, as.integer(B), overlaps, overlaps.P,
DUP=FALSE)
>
> then the corresponding element of test to matrix "overlaps"
> (test[["overlaps"]]) again has the updated values (correct
non-zero values)
> though the overlaps matrix itself is still empty.
>
> I mean in official R, the "overlaps" matrix is updated after
calling the
> function but not in R-devel. Also it works in both environment
and return
> correct values to variable "test" in R-devel as well.
> Did you face any similar problem so that R-devel does not update the
> variable returned by C++?
>
> Thanks for the help.
>
> [[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] R-devel does not update the C++ returned variables
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ code that receives them; you just need to think about the real
| problem, not the interface. It has its own learning curve, but I think
| it is easier than using the low-level code that you need to work with .Call.
Thanks for that vote, and I second that.
And these days the learning is a lot flatter than it was a decade ago:
R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) { return(2*x);
}")
R> doubleThis(c(1,2,3,21,-4))
[1] 2 4 6 42 -8
R>
That defined, compiled, loaded and run/illustrated a simple function.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] clarification on import/depends for a method
User of the coxme library (mixed effects Cox models) are instructed to use ranef(), fixed(), VarCorr(), etc to retrieve bits out of a fitted model; it purposely uses the same methods as nlme and/or lmer. The current behavior is to "depend" on nlme. If I defined the methods myself in coxme, then someone who had both nlme and coxme loaded will suffer from "last loaded wins", and the methods for one or the other are not found. I'm willing to update this but want to get it right. The import(nlme) + nlme::ranef(fit) solution is not appealing. I don't mind putting :: in my source code, but users of the package should not be forced into this. Is the correct current solution (using ranef as an example) importFrom(nlme, ranef) export(ranef) then use promptImport() to create a manual page? If users always had only one of coxme, lmer, or nlme loaded in any given session then there are multiple solutions, but occassionally one wants both linear and Cox mixed effects. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel does not update the C++ returned variables
Thanks! I went through the online posts which supports the power of .Call
over .C. But my probably naive question is why does this work for my code
with R but not R-devel?
And another question is related to using .Call. Based on the manual page, I
do not need to change the function parameters when using .Call. So I can
run like this:
.Call("sppedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N),
ssq[i], i, as.integer(B), overlaps, overlaps.P)
But I am receiving the memory(?) related error:
terminate called after throwing an instance of 'std::bad_alloc' what():
std::bad_alloc
Now that I am running the code using .Call.
Thanks.
On Mon, Mar 2, 2015 at 2:01 PM, Duncan Murdoch
wrote:
> On 02/03/2015 3:50 AM, sarah manderni wrote:
> > Hi,
> >
> > Within my R code, I am using a C++ function as below:
> >
> > overlaps <- matrix(0, nrow=B, ncol=length(N))
> > overlaps.P <- matrix(0, nrow=B, ncol=length(N))
> >
> >.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N), length(N),
> >ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE)
> >
> >
> > the function "speedUp", is supposed to update matrices overlaps and
> > overlaps.P and it works with official R versions.
> > However, using the same code in R-devel, it does not update matrices and
> > they remain all zero without returning any errors.
>
> See the NEWS: DUP=FALSE is now ignored. It led to too many bugs. Use
> the .Call interface if duplication causes problems.
>
> Duncan Murdoch
>
> > But, if I store the return values from C function in a variable lets say
> > "test" as follows:
> >
> > test <-.C("speedUp", D, S, pD, pS, nrow(D), as.integer(N),
> > length(N),
> >ssq[i], i, as.integer(B), overlaps, overlaps.P, DUP=FALSE)
> >
> > then the corresponding element of test to matrix "overlaps"
> > (test[["overlaps"]]) again has the updated values (correct non-zero
> values)
> > though the overlaps matrix itself is still empty.
> >
> > I mean in official R, the "overlaps" matrix is updated after calling the
> > function but not in R-devel. Also it works in both environment and return
> > correct values to variable "test" in R-devel as well.
> > Did you face any similar problem so that R-devel does not update the
> > variable returned by C++?
> >
> > Thanks for the help.
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel does not update the C++ returned variables
> On 2 March 2015 at 09:09, Duncan Murdoch wrote:
> | I generally recommend that people use Rcpp, which hides a lot of the
> | details. It will generate your .Call calls for you, and generate the
> | C++ code that receives them; you just need to think about the real
> | problem, not the interface. It has its own learning curve, but I think
> | it is easier than using the low-level code that you need to work with .Call.
> Thanks for that vote, and I second that.
> And these days the learning is a lot flatter than it was a decade ago:
> R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) {
> return(2*x); }")
> R> doubleThis(c(1,2,3,21,-4))
> [1] 2 4 6 42 -8
> R>
> That defined, compiled, loaded and run/illustrated a simple function.
> Dirk
Indeed impressive, ... and it also works with integer vectors
something also not 100% trivial when working with compiled code.
When testing that, I've went a step further:
## now "test":
require(microbenchmark)
i <- 1:10
(mb <- microbenchmark(doubleThis(i), i*2, 2*i, i*2L, 2L*i, i+i, times=2^12))
## Lynne (i7; FC 20), R Under development ... (2015-03-02 r67924):
## Unit: nanoseconds
## expr min lq mean median uq max neval cld
## doubleThis(i) 762 985 1319.5974 1124 1338 17831 4096 b
## i * 2 124 151 258.4419164 221 4 4096 a
## 2 * i 127 154 266.4707169 216 20213 4096 a
## i * 2L 143 164 250.6057181 234 16863 4096 a
## 2L * i 144 177 269.5015193 237 16119 4096 a
## i + i 152 183 272.6179199 243 10434 4096 a
plot(mb, log="y", notch=TRUE)
## hmm, looks like even the simple arithm. differ slightly ...
##
## ==> zoom in:
plot(mb, log="y", notch=TRUE, ylim = c(150,300))
dev.copy(png, file="mbenchm-doubling.png")
dev.off() # [ <- why do I need this here for png ??? ]
##--> see the appended *png graphic
Those who've learnt EDA or otherwise about boxplot notches, will
know that they provide somewhat informal but robust pairwise tests on
approximate 5% level.
>From these, one *could* - possibly wrongly - conclude that
'i * 2' is significantly faster than both 'i * 2L' and also
'i + i' which I find astonishing, given that i is integer here...
Probably no reason for deep thoughts here, but if someone is
enticed, this maybe slightly interesting to read.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] clarification on import/depends for a method
That makes sense to me. Hadley On Mon, Mar 2, 2015 at 8:45 AM, Therneau, Terry M., Ph.D. wrote: > User of the coxme library (mixed effects Cox models) are instructed to use > ranef(), fixed(), VarCorr(), etc to retrieve bits out of a fitted model; it > purposely uses the same methods as nlme and/or lmer. > > The current behavior is to "depend" on nlme. If I defined the methods > myself in coxme, then someone who had both nlme and coxme loaded will suffer > from "last loaded wins", and the methods for one or the other are not found. > I'm willing to update this but want to get it right. The import(nlme) + > nlme::ranef(fit) solution is not appealing. I don't mind putting :: in my > source code, but users of the package should not be forced into this. > > Is the correct current solution (using ranef as an example) >importFrom(nlme, ranef) >export(ranef) > > then use promptImport() to create a manual page? > > > If users always had only one of coxme, lmer, or nlme loaded in any given > session then there are multiple solutions, but occassionally one wants both > linear and Cox mixed effects. > > Terry T. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Errors on Windows with grep(fixed=TRUE) on UTF-8 strings
On Windows, grep(fixed=TRUE) throws errors with some UTF-8 strings.
Here's an example (must be run on Windows to reproduce the error):
Sys.setlocale("LC_CTYPE", "chinese")
y <- rawToChar(as.raw(c(0xe6, 0xb8, 0x97)))
Encoding(y) <- "UTF-8"
y
# [1] "渗"
grep("\n", y, fixed = TRUE)
# Error in grep("\n", y, fixed = TRUE) : invalid multibyte string at '<97>'
In my particular case, I'm using parse() on a string that contains
characters like this, and it triggers the same error, because parse()
calls srcfilecopy(), which calls grepl():
parse(text=y)
# Error in grepl("\n", lines, fixed = TRUE) :
# invalid multibyte string at '<97>'
Am I right in assuming that this isn't the expected behavior?
-Winston
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel does not update the C++ returned variables
On 2 March 2015 at 16:37, Martin Maechler wrote:
|
| > On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| > | I generally recommend that people use Rcpp, which hides a lot of the
| > | details. It will generate your .Call calls for you, and generate the
| > | C++ code that receives them; you just need to think about the real
| > | problem, not the interface. It has its own learning curve, but I think
| > | it is easier than using the low-level code that you need to work with
.Call.
|
| > Thanks for that vote, and I second that.
|
| > And these days the learning is a lot flatter than it was a decade ago:
|
| > R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) {
return(2*x); }")
| > R> doubleThis(c(1,2,3,21,-4))
| > [1] 2 4 6 42 -8
| > R>
|
| > That defined, compiled, loaded and run/illustrated a simple function.
|
| > Dirk
|
| Indeed impressive, ... and it also works with integer vectors
| something also not 100% trivial when working with compiled code.
|
| When testing that, I've went a step further:
As you may know, int can be 'casted up' to double which is what happens
here. So in what follows you _always_ create a copy from an int vector to a
numeric vector.
For pure int, use eg
Rcpp::cppFunction("IntegerVector doubleThis(IntegeerVector x) {
return(2*x); }")
and rename the function names as needed to have two defined concurrently.
Dirk
|
| ## now "test":
| require(microbenchmark)
| i <- 1:10
| (mb <- microbenchmark(doubleThis(i), i*2, 2*i, i*2L, 2L*i, i+i, times=2^12))
| ## Lynne (i7; FC 20), R Under development ... (2015-03-02 r67924):
| ## Unit: nanoseconds
| ## expr min lq mean median uq max neval cld
| ## doubleThis(i) 762 985 1319.5974 1124 1338 17831 4096 b
| ## i * 2 124 151 258.4419164 221 4 4096 a
| ## 2 * i 127 154 266.4707169 216 20213 4096 a
| ## i * 2L 143 164 250.6057181 234 16863 4096 a
| ## 2L * i 144 177 269.5015193 237 16119 4096 a
| ## i + i 152 183 272.6179199 243 10434 4096 a
|
| plot(mb, log="y", notch=TRUE)
| ## hmm, looks like even the simple arithm. differ slightly ...
| ##
| ## ==> zoom in:
| plot(mb, log="y", notch=TRUE, ylim = c(150,300))
|
| dev.copy(png, file="mbenchm-doubling.png")
| dev.off() # [ <- why do I need this here for png ??? ]
| ##--> see the appended *png graphic
|
| Those who've learnt EDA or otherwise about boxplot notches, will
| know that they provide somewhat informal but robust pairwise tests on
| approximate 5% level.
| >From these, one *could* - possibly wrongly - conclude that
| 'i * 2' is significantly faster than both 'i * 2L' and also
| 'i + i' which I find astonishing, given that i is integer here...
|
| Probably no reason for deep thoughts here, but if someone is
| enticed, this maybe slightly interesting to read.
|
| Martin Maechler, ETH Zurich
|
| [DELETED ATTACHMENT mbenchm-doubling.png, PNG image]
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel does not update the C++ returned variables
On 03/02/2015 04:37 PM, Martin Maechler wrote:
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ code that receives them; you just need to think about the real
| problem, not the interface. It has its own learning curve, but I think
| it is easier than using the low-level code that you need to work with .Call.
Thanks for that vote, and I second that.
And these days the learning is a lot flatter than it was a decade ago:
R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) { return(2*x);
}")
R> doubleThis(c(1,2,3,21,-4))
[1] 2 4 6 42 -8
R>
That defined, compiled, loaded and run/illustrated a simple function.
Dirk
Indeed impressive, ... and it also works with integer vectors
something also not 100% trivial when working with compiled code.
When testing that, I've went a step further:
## now "test":
require(microbenchmark)
i <- 1:10
Note that the relative speed of the algorithms also depends on the size
of the input vector. i + i becomes the winner for longer vectors (e.g. i
<- 1:1e6), but a proper Rcpp version is still approximately twice as fast.
Rcpp::cppFunction("NumericVector doubleThisNum(NumericVector x) {
return(2*x); }")
Rcpp::cppFunction("IntegerVector doubleThisInt(IntegerVector x) {
return(2*x); }")
i <- 1:1e6
mb <- microbenchmark::microbenchmark(doubleThisNum(i), doubleThisInt(i),
i*2, 2*i, i*2L, 2L*i, i+i, times=100)
plot(mb, log="y", notch=TRUE)
(mb <- microbenchmark(doubleThis(i), i*2, 2*i, i*2L, 2L*i, i+i, times=2^12))
## Lynne (i7; FC 20), R Under development ... (2015-03-02 r67924):
## Unit: nanoseconds
## expr min lq mean median uq max neval cld
## doubleThis(i) 762 985 1319.5974 1124 1338 17831 4096 b
## i * 2 124 151 258.4419164 221 4 4096 a
## 2 * i 127 154 266.4707169 216 20213 4096 a
## i * 2L 143 164 250.6057181 234 16863 4096 a
## 2L * i 144 177 269.5015193 237 16119 4096 a
## i + i 152 183 272.6179199 243 10434 4096 a
plot(mb, log="y", notch=TRUE)
## hmm, looks like even the simple arithm. differ slightly ...
##
## ==> zoom in:
plot(mb, log="y", notch=TRUE, ylim = c(150,300))
dev.copy(png, file="mbenchm-doubling.png")
dev.off() # [ <- why do I need this here for png ??? ]
##--> see the appended *png graphic
Those who've learnt EDA or otherwise about boxplot notches, will
know that they provide somewhat informal but robust pairwise tests on
approximate 5% level.
From these, one *could* - possibly wrongly - conclude that
'i * 2' is significantly faster than both 'i * 2L' and also
'i + i' which I find astonishing, given that i is integer here...
Probably no reason for deep thoughts here, but if someone is
enticed, this maybe slightly interesting to read.
Martin Maechler, ETH Zurich
__
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-devel does not update the C++ returned variables
On 03/02/2015 11:39 AM, Dirk Eddelbuettel wrote:
On 2 March 2015 at 16:37, Martin Maechler wrote:
|
| > On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| > | I generally recommend that people use Rcpp, which hides a lot of the
| > | details. It will generate your .Call calls for you, and generate the
| > | C++ code that receives them; you just need to think about the real
| > | problem, not the interface. It has its own learning curve, but I think
| > | it is easier than using the low-level code that you need to work with
.Call.
|
| > Thanks for that vote, and I second that.
|
| > And these days the learning is a lot flatter than it was a decade ago:
|
| > R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) { return(2*x);
}")
| > R> doubleThis(c(1,2,3,21,-4))
| > [1] 2 4 6 42 -8
| > R>
|
| > That defined, compiled, loaded and run/illustrated a simple function.
|
| > Dirk
|
| Indeed impressive, ... and it also works with integer vectors
| something also not 100% trivial when working with compiled code.
|
| When testing that, I've went a step further:
As you may know, int can be 'casted up' to double which is what happens
here. So in what follows you _always_ create a copy from an int vector to a
numeric vector.
For pure int, use eg
Rcpp::cppFunction("IntegerVector doubleThis(IntegeerVector x) { return(2*x);
}")
and rename the function names as needed to have two defined concurrently.
avoiding duplication, harmless in the doubleThis() case, comes at some
considerable hazard in general
> Rcpp::cppFunction("IntegerVector incrThisAndThat(IntegerVector x) { x[0] +=
1; return x; }")
> x = y = 1:5
> incrThisAndThat(x)
[1] 2 2 3 4 5
> x
[1] 2 2 3 4 5
> y
[1] 2 2 3 4 5
(how often this happens in the now relatively large number of user-contributed
packages using Rcpp?). It seems like 'one-liners' should really encourage
something safer (sometimes at the expense of 'speed'),
Rcpp::cppFunction("IntegerVector doubleThis(const IntegerVector x) { return x
* 2; }")
Rcpp::cppFunction("std::vector incrThis(std::vector x) { x[0] += 1;
return x; }")
or that Rcpp should become more careful (i.e., should not allow!) modifying
arguments with NAMED != 0.
Martin (Morgan)
Dirk
|
| ## now "test":
| require(microbenchmark)
| i <- 1:10
| (mb <- microbenchmark(doubleThis(i), i*2, 2*i, i*2L, 2L*i, i+i, times=2^12))
| ## Lynne (i7; FC 20), R Under development ... (2015-03-02 r67924):
| ## Unit: nanoseconds
| ## expr min lq mean median uq max neval cld
| ## doubleThis(i) 762 985 1319.5974 1124 1338 17831 4096 b
| ## i * 2 124 151 258.4419164 221 4 4096 a
| ## 2 * i 127 154 266.4707169 216 20213 4096 a
| ## i * 2L 143 164 250.6057181 234 16863 4096 a
| ## 2L * i 144 177 269.5015193 237 16119 4096 a
| ## i + i 152 183 272.6179199 243 10434 4096 a
|
| plot(mb, log="y", notch=TRUE)
| ## hmm, looks like even the simple arithm. differ slightly ...
| ##
| ## ==> zoom in:
| plot(mb, log="y", notch=TRUE, ylim = c(150,300))
|
| dev.copy(png, file="mbenchm-doubling.png")
| dev.off() # [ <- why do I need this here for png ??? ]
| ##--> see the appended *png graphic
|
| Those who've learnt EDA or otherwise about boxplot notches, will
| know that they provide somewhat informal but robust pairwise tests on
| approximate 5% level.
| >From these, one *could* - possibly wrongly - conclude that
| 'i * 2' is significantly faster than both 'i * 2L' and also
| 'i + i' which I find astonishing, given that i is integer here...
|
| Probably no reason for deep thoughts here, but if someone is
| enticed, this maybe slightly interesting to read.
|
| Martin Maechler, ETH Zurich
|
| [DELETED ATTACHMENT mbenchm-doubling.png, PNG image]
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel does not update the C++ returned variables
Hi,
On 03/02/2015 12:18 PM, Dénes Tóth wrote:
On 03/02/2015 04:37 PM, Martin Maechler wrote:
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ code that receives them; you just need to think about the real
| problem, not the interface. It has its own learning curve, but I
think
| it is easier than using the low-level code that you need to work
with .Call.
Thanks for that vote, and I second that.
And these days the learning is a lot flatter than it was a decade ago:
R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) {
return(2*x); }")
R> doubleThis(c(1,2,3,21,-4))
[1] 2 4 6 42 -8
R>
That defined, compiled, loaded and run/illustrated a simple function.
Dirk
Indeed impressive, ... and it also works with integer vectors
something also not 100% trivial when working with compiled code.
When testing that, I've went a step further:
## now "test":
require(microbenchmark)
i <- 1:10
Note that the relative speed of the algorithms also depends on the size
of the input vector. i + i becomes the winner for longer vectors (e.g. i
<- 1:1e6), but a proper Rcpp version is still approximately twice as fast.
The difference in speed is probably due to the fact that R does safe
arithmetic. C or C++ do not:
> doubleThisInt(i)
[1] 2147483642 2147483644 2147483646 NA -2147483646
-2147483644
> 2L * i
[1] 2147483642 2147483644 2147483646 NA NA NA
Warning message:
In 2L * i : NAs produced by integer overflow
H.
Rcpp::cppFunction("NumericVector doubleThisNum(NumericVector x) {
return(2*x); }")
Rcpp::cppFunction("IntegerVector doubleThisInt(IntegerVector x) {
return(2*x); }")
i <- 1:1e6
mb <- microbenchmark::microbenchmark(doubleThisNum(i), doubleThisInt(i),
i*2, 2*i, i*2L, 2L*i, i+i, times=100)
plot(mb, log="y", notch=TRUE)
(mb <- microbenchmark(doubleThis(i), i*2, 2*i, i*2L, 2L*i, i+i,
times=2^12))
## Lynne (i7; FC 20), R Under development ... (2015-03-02 r67924):
## Unit: nanoseconds
## expr min lq mean median uq max neval cld
## doubleThis(i) 762 985 1319.5974 1124 1338 17831 4096 b
## i * 2 124 151 258.4419164 221 4 4096 a
## 2 * i 127 154 266.4707169 216 20213 4096 a
## i * 2L 143 164 250.6057181 234 16863 4096 a
## 2L * i 144 177 269.5015193 237 16119 4096 a
## i + i 152 183 272.6179199 243 10434 4096 a
plot(mb, log="y", notch=TRUE)
## hmm, looks like even the simple arithm. differ slightly ...
##
## ==> zoom in:
plot(mb, log="y", notch=TRUE, ylim = c(150,300))
dev.copy(png, file="mbenchm-doubling.png")
dev.off() # [ <- why do I need this here for png ??? ]
##--> see the appended *png graphic
Those who've learnt EDA or otherwise about boxplot notches, will
know that they provide somewhat informal but robust pairwise tests on
approximate 5% level.
From these, one *could* - possibly wrongly - conclude that
'i * 2' is significantly faster than both 'i * 2L' and also
'i + i' which I find astonishing, given that i is integer here...
Probably no reason for deep thoughts here, but if someone is
enticed, this maybe slightly interesting to read.
Martin Maechler, ETH Zurich
__
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
--
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...@fredhutch.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] R-devel does not update the C++ returned variables
On 03/02/2015 01:00 PM, Hervé Pagès wrote:
Hi,
On 03/02/2015 12:18 PM, Dénes Tóth wrote:
On 03/02/2015 04:37 PM, Martin Maechler wrote:
On 2 March 2015 at 09:09, Duncan Murdoch wrote:
| I generally recommend that people use Rcpp, which hides a lot of the
| details. It will generate your .Call calls for you, and generate the
| C++ code that receives them; you just need to think about the real
| problem, not the interface. It has its own learning curve, but I
think
| it is easier than using the low-level code that you need to work
with .Call.
Thanks for that vote, and I second that.
And these days the learning is a lot flatter than it was a decade ago:
R> Rcpp::cppFunction("NumericVector doubleThis(NumericVector x) {
return(2*x); }")
R> doubleThis(c(1,2,3,21,-4))
[1] 2 4 6 42 -8
R>
That defined, compiled, loaded and run/illustrated a simple function.
Dirk
Indeed impressive, ... and it also works with integer vectors
something also not 100% trivial when working with compiled code.
When testing that, I've went a step further:
## now "test":
require(microbenchmark)
i <- 1:10
Note that the relative speed of the algorithms also depends on the size
of the input vector. i + i becomes the winner for longer vectors (e.g. i
<- 1:1e6), but a proper Rcpp version is still approximately twice as
fast.
The difference in speed is probably due to the fact that R does safe
arithmetic. C or C++ do not:
> doubleThisInt(i)
[1] 2147483642 2147483644 2147483646 NA -2147483646
-2147483644
> 2L * i
[1] 2147483642 2147483644 2147483646 NA NA NA
Warning message:
In 2L * i : NAs produced by integer overflow
That was with
i <- as.integer(2^30-4) + 1:6
Cheers,
H.
H.
Rcpp::cppFunction("NumericVector doubleThisNum(NumericVector x) {
return(2*x); }")
Rcpp::cppFunction("IntegerVector doubleThisInt(IntegerVector x) {
return(2*x); }")
i <- 1:1e6
mb <- microbenchmark::microbenchmark(doubleThisNum(i), doubleThisInt(i),
i*2, 2*i, i*2L, 2L*i, i+i, times=100)
plot(mb, log="y", notch=TRUE)
(mb <- microbenchmark(doubleThis(i), i*2, 2*i, i*2L, 2L*i, i+i,
times=2^12))
## Lynne (i7; FC 20), R Under development ... (2015-03-02 r67924):
## Unit: nanoseconds
## expr min lq mean median uq max neval cld
## doubleThis(i) 762 985 1319.5974 1124 1338 17831 4096 b
## i * 2 124 151 258.4419164 221 4 4096 a
## 2 * i 127 154 266.4707169 216 20213 4096 a
## i * 2L 143 164 250.6057181 234 16863 4096 a
## 2L * i 144 177 269.5015193 237 16119 4096 a
## i + i 152 183 272.6179199 243 10434 4096 a
plot(mb, log="y", notch=TRUE)
## hmm, looks like even the simple arithm. differ slightly ...
##
## ==> zoom in:
plot(mb, log="y", notch=TRUE, ylim = c(150,300))
dev.copy(png, file="mbenchm-doubling.png")
dev.off() # [ <- why do I need this here for png ??? ]
##--> see the appended *png graphic
Those who've learnt EDA or otherwise about boxplot notches, will
know that they provide somewhat informal but robust pairwise tests on
approximate 5% level.
From these, one *could* - possibly wrongly - conclude that
'i * 2' is significantly faster than both 'i * 2L' and also
'i + i' which I find astonishing, given that i is integer here...
Probably no reason for deep thoughts here, but if someone is
enticed, this maybe slightly interesting to read.
Martin Maechler, ETH Zurich
__
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
--
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...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Import data set from another package?
I've moved nlme from Depends to Imports in my coxme package. However, a few of the examples for lmekin use one of the data sets from nlme. This is on purpose, to show how the results are the same and how they differ. If I use data(nlme::ergoStool) the data is not found, data(nlme:::ergoStool) does no better. If I add importFrom(nlme, "ergoStool") the error message is that ergoStool is not exported. There likely is a simple way, but I currently don't see it. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Import data set from another package?
On 03/02/2015 04:48 PM, Therneau, Terry M., Ph.D. wrote:
I've moved nlme from Depends to Imports in my coxme package. However, a
few of the examples for lmekin use one of the data sets from nlme. This
is on purpose, to show how the results are the same and how they differ.
If I use data(nlme::ergoStool) the data is not found,
data(nlme:::ergoStool) does no better.
If I add importFrom(nlme, "ergoStool") the error message is that
ergoStool is not exported.
There likely is a simple way, but I currently don't see it.
In your examples, can't you use:
data("ergoStool", package="nlme")
?
That is how a user would call it if they wished to use the dataset.
Regards,
Brian
--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Import data set from another package?
How about just nlme::ergoStool ? Hadley On Mon, Mar 2, 2015 at 4:48 PM, Therneau, Terry M., Ph.D. wrote: > I've moved nlme from Depends to Imports in my coxme package. However, a few > of the examples for lmekin use one of the data sets from nlme. This is on > purpose, to show how the results are the same and how they differ. > > If I use data(nlme::ergoStool) the data is not found, > data(nlme:::ergoStool) does no better. > If I add importFrom(nlme, "ergoStool") the error message is that ergoStool > is not exported. > > There likely is a simple way, but I currently don't see it. > > Terry T. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Import data set from another package?
You could add something like this to your package:
.onLoad <- function(libname, pkgname){
data(ergoStool, package="nlme", envir = environment(.onLoad));
}
This should basically do the same as importFrom(nlme, "ergoStool") but
then for a lazy load dataset.
On Mon, Mar 2, 2015 at 2:48 PM, Therneau, Terry M., Ph.D.
wrote:
> I've moved nlme from Depends to Imports in my coxme package. However, a few
> of the examples for lmekin use one of the data sets from nlme. This is on
> purpose, to show how the results are the same and how they differ.
>
> If I use data(nlme::ergoStool) the data is not found,
> data(nlme:::ergoStool) does no better.
> If I add importFrom(nlme, "ergoStool") the error message is that ergoStool
> is not exported.
>
> There likely is a simple way, but I currently don't see it.
>
> Terry T.
>
> __
> 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
