[Rd] Possible page inefficiency in do_matrix in array.c
In do_matrix in src/array.c there is a type switch containing : case LGLSXP : for (i = 0; i < nr; i++) for (j = 0; j < nc; j++) LOGICAL(ans)[i + j * NR] = NA_LOGICAL; That seems page inefficient, iiuc. Think it should be : case LGLSXP : for (j = 0; j < nc; j++) for (i = 0; i < nr; i++) LOGICAL(ans)[i + j * NR] = NA_LOGICAL; or more simply : case LGLSXP : for (i = 0; i < nc*nr; i++) LOGICAL(ans)[i] = NA_LOGICAL; ( with some fine tuning required since NR is type R_xlen_t whilst i, nc and nr are type int ). Same goes for all the other types in that switch. This came up on Stack Overflow here : http://stackoverflow.com/questions/12220128/reason-for-faster-matrix-allocation-in-r Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible page inefficiency in do_matrix in array.c
On Sep 2, 2012, at 10:04 PM, Matthew Dowle wrote: > > In do_matrix in src/array.c there is a type switch containing : > > case LGLSXP : >for (i = 0; i < nr; i++) >for (j = 0; j < nc; j++) >LOGICAL(ans)[i + j * NR] = NA_LOGICAL; > > That seems page inefficient, iiuc. Think it should be : > > case LGLSXP : >for (j = 0; j < nc; j++) >for (i = 0; i < nr; i++) >LOGICAL(ans)[i + j * NR] = NA_LOGICAL; > > or more simply : > > case LGLSXP : >for (i = 0; i < nc*nr; i++) >LOGICAL(ans)[i] = NA_LOGICAL; > > ( with some fine tuning required since NR is type R_xlen_t whilst i, nc > and nr are type int ). > > Same goes for all the other types in that switch. > > This came up on Stack Overflow here : > http://stackoverflow.com/questions/12220128/reason-for-faster-matrix-allocation-in-r > That is completely irrelevant - modern compilers will optimize the loops accordingly and there is no difference in speed. If you don't believe it, run benchmarks ;) original > microbenchmark(matrix(nrow=1, ncol=), times=10) Unit: milliseconds expr min lq median uq max 1 matrix(nrow = 1, ncol = ) 940.5519 940.6644 941.136 954.7196 1409.901 swapped > microbenchmark(matrix(nrow=1, ncol=), times=10) Unit: milliseconds expr min lq median uq max 1 matrix(nrow = 1, ncol = ) 949.9638 950.6642 952.7497 961.001 1246.573 Cheers, Simon > Matthew > > __ > 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] Possible page inefficiency in do_matrix in array.c
Actually, my apologies, I was assuming that your example was based on the SO question while it is not at all (the code is not involved in that test case). Reversing the order does indeed cause a delay. Switching to a single index doesn't seem to have any impact. R-devel has the faster version now (which now also works with large vectors). Cheers, Simon On Sep 2, 2012, at 10:32 PM, Simon Urbanek wrote: > On Sep 2, 2012, at 10:04 PM, Matthew Dowle wrote: > >> >> In do_matrix in src/array.c there is a type switch containing : >> >> case LGLSXP : >> for (i = 0; i < nr; i++) >> for (j = 0; j < nc; j++) >> LOGICAL(ans)[i + j * NR] = NA_LOGICAL; >> >> That seems page inefficient, iiuc. Think it should be : >> >> case LGLSXP : >> for (j = 0; j < nc; j++) >> for (i = 0; i < nr; i++) >> LOGICAL(ans)[i + j * NR] = NA_LOGICAL; >> >> or more simply : >> >> case LGLSXP : >> for (i = 0; i < nc*nr; i++) >> LOGICAL(ans)[i] = NA_LOGICAL; >> >> ( with some fine tuning required since NR is type R_xlen_t whilst i, nc >> and nr are type int ). >> >> Same goes for all the other types in that switch. >> >> This came up on Stack Overflow here : >> http://stackoverflow.com/questions/12220128/reason-for-faster-matrix-allocation-in-r >> > > That is completely irrelevant - modern compilers will optimize the loops > accordingly and there is no difference in speed. If you don't believe it, run > benchmarks ;) > > original >> microbenchmark(matrix(nrow=1, ncol=), times=10) > Unit: milliseconds > expr min lq median uq max > 1 matrix(nrow = 1, ncol = ) 940.5519 940.6644 941.136 954.7196 > 1409.901 > > > swapped >> microbenchmark(matrix(nrow=1, ncol=), times=10) > Unit: milliseconds > expr min lq median uq max > 1 matrix(nrow = 1, ncol = ) 949.9638 950.6642 952.7497 961.001 > 1246.573 > > Cheers, > Simon > > >> Matthew >> >> __ >> 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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] if(--as-cran)?
Hello, All:
The fda package has tests that run too long for CRAN's current
rules. I'd like to wrap some examples in a construct like the following:
if(!CRAN()){
...
}
I tried the following:
CRAN <- function(x='_R_CHECK_CRAN_INCOMING_'){
x. <- Sys.getenv(x)
xl <- as.logical(x.)
notCRAN <- is.na(xl) || xl
#
return(!notCRAN)
}
The companion help page included the following example:
if(CRAN()){
stop('CRAN')
} else {
stop('NOT CRAN')
}
This reported "NOT CRAN" even with "R CMD check --as-cran".
Suggestions?
Thanks,
Spencer
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] sos_1.3-5 brew_1.0-6
loaded via a namespace (and not attached):
[1] tools_2.15.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
