But now that I read your initial example more carefully, you could also do:
fx<- cxxfunction( , '
RNGScope scope ;
NumericMatrix hrcc( 3, 10) ;
for( int i=0; i<10; i++) hrcc(_,i) = runif(3) ;
return hrcc ;
', plugin = "Rcpp" )
fx()
Yes, apologies my sugar example was a bit mis-typed and not very clear. thanks
for your suggestions and *disambiguating the runif*.
Your last one (the above) is how i'm doing it for now (but looping over hrcc(i,_)). Although in my real code
the "10" is more like "10^8" and the "3" is between 10 and 200.
so that hrcc is a matrix of (say) rows=10, cols=10^8.
Hence trying to avoid using "for" altogether. I think looping over the smaller
"row" dimension would probably be ok...I need to test this. But thanks.
________________________________________
From: [email protected]
[[email protected]] on behalf of Romain Francois
[[email protected]]
Sent: 13 December 2010 10:07
To: [email protected]
Subject: Re: [Rcpp-devel] Sugar/inline and RTools
Hello,
Le 12/12/10 16:28, Dirk Eddelbuettel a écrit :
Hi Chris,
On 12 December 2010 at 15:03, Wray, Christopher wrote:
| Hi,
| Im using windows7, R2.12, Rtools2.12 and all the latest packages of inline,
| rcpp, etc. Over the last few weeks I have managed to get loads of the
| examples working, and all makes sense and is pretty clear. I had a couple of
| questions/comments:
|
| 1. RTools: On windows, I understand that Rcpp and R depend in a critical way
upon RTools.
Yes. While one conceptually could also use other builds of the gcc compiler,
in practice this can backfire when library interactions, underscore
conventions, ... go wrong. For experts-only --- while "Depend" may be a
strong a term, for us as package authors it is simply an easy and reliable
way to follow R Core's lead and assume this toolchain to ensure identical
behaviour. Now, this has one known cost which is ...
| I have recently been rewriting some parallelized C++ code that uses omp.h
| and the RcppAramdillo plugin.
... that Rtools famously does not support OpenMP. I think this come up both
here and on r-devel in the last few weeks.
Duncan M's response basically was that the support in Rtools is for what R /
R Core needs --- hence no Open MP. I know of at least one package on CRAN
which disables Open MP on Windows (as CRAN doesn't have it) but provides Open
MP-enabled windows binaries at its site.
| Im also a fan of running code snippits using inline, etc. RTools does not
| provide full suport for omp (no real surprise given the "minimum"GW
| distribution). So I had to add libpthreads, etc, to my RTools installation
| (libgomp is already included) and use "cppargs= -fopenmp" and "libargs =
| -lgomp -lpthread" when using "cfunction" from inline. All works fine
| though. Is it *only* the core R build process that determines what RTools
That is my understanding.
| toolchain contains? Could this change with more usage of Rcpp (on windows)?
| Duncan Murdoch who maintains RTools pointed me in the right direction, to
| find this solution.
Yup. If you were to create, maintain, distribute, ... a new toolchain
including Open MP / libgomp for Windows it would certainly be appreciated.
CRAN may even end up using it. Or maybe liaise with Duncan M / Brian R and
help them. Dunno.
Romain and I are not particular heavy users of Windows so we are very
unlikely to be volunteering here. I plan to do some work with Open MP for
parallelised optimisation but I will surely do my work on Linux. But if and
when I am done there I'd probably be asking the same questions. So let's keep
that question in mind for future discussions.
I don't have much to add here. Duncan is definitely the one you should
negociate with.
I don't use windows, apart from testing that "Rcpp works" and I have not
used OpenMP either.
| 2. As far as I can tell the "cxxfunction" does not allow the passing of
| *additional* PKG_CPPFLAGS and PKG_LIBS args explictly (these are set from
| "env<- settings$env" with "do.call(Sys.setenv, env)" if a plugin is
| used). Is there a cleaner way of passing compiler options/flags when using
| cxxfunction + plugin? I do appreciate that plugins circumvent the need for
| such compiler options, etc, and so I guess this is somewhat of a
| pathological example. Right now, I'm using my own hacked version of
| cxxfunction to pass the additional flags (in 1.) to get parallel code to
| compile (on windows).
Maybe you can contribute a clean patch to inline (and its manual page etc)
that we can review? Romain and I are ipso facto maintainers of inline now
that Oleg has no new needs whereas we do come across new use cases.
Alternatively, you could possibly write yourself (and / or the world via
CRAN) a support package 'RcppOMP' whose sole / main purpose it is to provide
a plugin for inline. The hooks are there...
You don't necesarilly have to make a package for this. You can register
an inline plugin "manually".
plug<- function(){
settings<- getPlugin( "Rcpp" )
settings$env[["PKG_CPPFLAGS"]]<- "whatever you need"
settings
}
registerPlugin( "omp", plug )
so that you can then do plugin = "omp"
| 3. Rcpp::sugar. I have been trying to replicate this R snippet using sugar,
but have not had much luck:
| R> sapply(rep(3,100), runif)
| This returns a column major matrix of size 3x10.
|
| I tried (column assigment):
|
| int N = as<int>(nn); //N=3
| NumericMatrix hrcc;
| for(int k=0; k<100; k++){
| hrcc(_,k) = sapply(N, runif);}
|
| But the compiler complains about runif being overloaded and not resolved. I
| have checked for examples and docs and looked at the sugar unit tests
| also. Am I doing something stupid? Do I need to specify runif more
| carefully? Am I using or assiging NumericMatrix incorrectly?
Not sure. I could try later. From the top of my head I'd try to split
operations first: have sugar create a vector (all the r* vectors are
internally vectorised so runif(N) should give you a vector, no need for
sapply); test the vector and then assign the vectors to hrcc. But you could
probably also the whole matrix at once.
Dirk
In R, I would do :
matrix( runif( 300), nrow = 3 )
You can sort of do the same in Rcpp :
require(Rcpp)
require(inline)
fx<- cxxfunction( , '
RNGScope scope ;
NumericVector y = runif( 30 ) ;
y.attr("dim") = Dimension(3,10) ;
return y ;
', plugin = "Rcpp" )
fx()
This is kind of messy because y will only have a vector interface, and
not look like a matrix, you can perhaps cheat like this:
fx<- cxxfunction( , '
RNGScope scope ;
NumericMatrix m = make_matrix(3, 10 ) ;
return m ;
', includes ='
SEXP make_matrix( int nr, int nc){
NumericVector y = runif( nr*nc) ;
y.attr("dim") = Dimension(nr,nc) ;
return y ;
}
', plugin = "Rcpp" )
fx()
Otherwise, you have to help the compiler by disambiguating the runif
overload manually:
fx<- cxxfunction( , '
RNGScope scope ;
List res = sapply( rep(10,3), my_runif ) ;
return res ;
', includes='
NumericVector (*my_runif)(int) = runif ;
', plugin = "Rcpp" )
fx()
The line :
NumericVector (*my_runif)(int) = runif ;
does the disambiguating.
Note that sugar's sapply does not simplify its output to a matrix. This
is somewhat too difficult to achieve.
But now that I read your initial example more carefully, you could also do:
fx<- cxxfunction( , '
RNGScope scope ;
NumericMatrix hrcc( 3, 10) ;
for( int i=0; i<10; i++) hrcc(_,i) = runif(3) ;
return hrcc ;
', plugin = "Rcpp" )
fx()
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
