Re: [Rcpp-devel] RcppParallel on Solaris
Le 13 avr. 2015 à 14:03, JJ Allaire jj.alla...@gmail.com a écrit : That's excellent I just updated the branch to reflect this change and also successfully ran the tests on the Solaris config that you provided me access to. I'll have to take a closer look at the warnings. One other issue that needs to be resolved prior to the next submission to CRAN revolves around pedantic warnings on Debian testing that prohibit long long (used by both TinyThread and TBB). The easy workaround is SystemRequirements: C++11 however this will mean that package won't compile on pre-Mavericks Macs (~30% of all Macs) nor RedHat/CentOS systems. Perhaps I can modify TinyThread and TBB to no longer use long long but I'll need to do this very carefully. FWIW tbb with C++11, in particular lambdas is awesome On Sun, Apr 12, 2015 at 10:30 PM, Gábor Csárdi csardi.ga...@gmail.com wrote: Hi JJ all, I had some time, had an idea, and made it to work. The problem was that TBB was not compiled with the same flags as R and the rest of the R package, so just had to find what is the difference that is incompatible. It is simple, you need to compile TBB with -library=stlport4 So if you change line 34 in SunOS.suncc.inc to CPLUS = CC -library=stlport4 then it compiles and installs fine. What's even better, the tests run fine, too. They spit out a lot of compiler warnings, but they all pass. Best, Gabor On Wed, Apr 8, 2015 at 11:38 AM, Gábor Csárdi csardi.ga...@gmail.com wrote: Ok, the server seems to work. JJ, I'll send you a private email. If anyone wants access, please email me in private. Remember that this is just a mac mini, so it might not be super fast. It seems fast enough for a single user, though. Gabor On Tue, Apr 7, 2015 at 7:17 PM, Gábor Csárdi csardi.ga...@gmail.com wrote: On Tue, Apr 7, 2015 at 6:50 PM, Jeroen Ooms jeroeno...@gmail.com wrote: [...] So that's why I thought they probably use GCC for packages that don't work with Solaris Studio. I see. That would indeed make sense. G. ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] RInside vs Statconndcom
RInside is not really about performance. it’s just a way to easily embed R in a C++ application. Le 4 avr. 2015 à 19:54, Jodi Jhouranda Siregar 11.6...@stis.ac.id a écrit : I'm on my project developing user interface for r. I dicided to use rinside. And i want to know which is better in term of peformance, RInside or statconndcom ? For the reason why using RInside is better than statconndcom. Thanks. ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp Parallel and Rcpp Armadillo
Some pointers.
When you use an arma::mat passed by value in an Rcpp::export, this means
copying all of the data of the underlying R object into armadillo. I’d suggest
you use a reference to const to avoid that, i.e.
mat contrib1(const mat X1) { … }
Then in pQnorm, you do:
NumericMatrix x_q = Rcpp::asRcpp::NumericMatrix(wrap(xx_q));
That is yet again, copying all of the data from the arma::mat into an Rcpp
matrix.
You then return a arma::mat, which data is copied implicitly as the return of
contrib1.
I’d suggest you do all this without armadillo, which you don’t really use
except for inducing a lot of extra copies of data.
To anwser your last question, R uses a garbage collector, so the memory is not
automatically reclaimed as soon as it is no longer needed.
Hope this helps.
Romain
Le 10 déc. 2014 à 15:01, Maxime To maxime...@outlook.fr a écrit :
Hi,
I changed the function as indicated by Dirk and I modify the functions and
the program does work now.
However, I am still puzzled by the memory use of the program. when I run a
loop of my function in R as in the code below, it seems that the program does
not free the memory used in the previous iterations... which is annoying when
I need to optimize on my final object.
So I was wondering whether it was a question of declaration of object in my
code?
--
sourceCpp(Rcpp/test.cpp) #
qwe = matrix(runif(1), nrow = 100)
a = contrib1(qwe)
b = qnorm(qwe)
a - b
for (i in 1:2) a = contrib1(qwe)
--
// test.cpp
#include RcppArmadillo.h
#include cmath
#include algorithm
#include RcppParallel.h
#include boost/math/distributions/inverse_gaussian.hpp
using namespace Rcpp;
using namespace arma;
using namespace std;
using namespace RcppParallel;
// [[Rcpp::depends(RcppArmadillo, RcppParallel, BH)]]
double qnorm_f(const double x_q) {
boost::math::normal s;
return boost::math::quantile(s, x_q);
};
struct Qnorm : public Worker
{
// source matrix
const RMatrixdouble input_q;
// destination matrix
RMatrixdouble output_q;
// initialize with source and destination
Qnorm(const NumericMatrix input_q, NumericMatrix output_q)
: input_q(input_q), output_q(output_q) {}
// take the Pnorm of the range of elements requested
void operator()(std::size_t begin, std::size_t end) {
std::transform(input_q.begin() + begin,
input_q.begin() + end,
output_q.begin() + begin,
::qnorm_f);
}
};
mat pQnorm(mat xx_q) {
NumericMatrix x_q = Rcpp::asRcpp::NumericMatrix(wrap(xx_q));
// allocate the output matrix
const NumericMatrix output_q(x_q.nrow(), x_q.ncol());
// Pnorm functor (pass input and output matrices)
Qnorm qnorm_temp(x_q, output_q);
// call parallelFor to do the work
parallelFor(0, x_q.length(), qnorm_temp);
// return the output matrix
mat outmat_q(output_q.begin(), output_q.nrow(),output_q.ncol());
return outmat_q;
}
// [[Rcpp::export]]
mat contrib1(mat X1) {
mat test= pQnorm(X1);
mat results = test;
return results;
}
--
Date: Tue, 9 Dec 2014 09:07:10 -0600
To: q...@umail.iu.edu mailto:q...@umail.iu.edu
CC: maxime...@outlook.fr mailto:maxime...@outlook.fr;
rcpp-devel@lists.r-forge.r-project.org
mailto:rcpp-devel@lists.r-forge.r-project.org
Subject: Re: [Rcpp-devel] Rcpp Parallel and Rcpp Armadillo
From: e...@debian.org mailto:e...@debian.org
On 9 December 2014 at 09:46, Qiang Kou wrote:
| What do you mean by doesn't work ? Compiling error or the result is not
| right?
|
| I just tried the code, and it seems the code can compile and work.
I am generally very careful about calling back to anything related to R from
functions to be parallelized. So for
inline double f(double x) { return ::Rf_pnorm5(x, 0.0, 1.0, 1, 0); }
I think going with an equivalent pnorm() function from Boost / Bh may be
better.
But I am shooting from my hip here as I have not had time to look at this,
having been out way too late at a nice concert :)
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp and ExternalPtr
You are looking for XPtr.
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/XPtr.h
It is a template class whose first parameter is the class of the raw pointer
you are dealing with, let’s call it T.
You can create an external pointer using something like :
XPtrT xp( new T(...) ) ;
This registers the default finalizer (which calls delete) to be executed when R
garbage collects the R object. So you can send xp back to the R side.
Then you can grab it back on the C++ side, e.g. as a parameter to a function:
// [[Rcpp::export]]
void foo( XPtrT xp ){
// here you can treat xp as a raw pointer, e.g. do xp-foo( ... ) ;
}
You can also set the finalizer yourself with a bit more work if you wanted to
do something different than the default, e.g.
void my_finalizer( T* obj ){
// whatever you need to do
}
typedef XPtrT, PreserveStorage, my_finalizer Bar ;
If you deal with a pointer that you don’t own, i.e. you don’t handle its
finalization for some reason, you can set the second parameter of the XPtr
constructor from
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/XPtr.h#L84
XPtrT xp( raw_ptr, false ) ;
Romain
Le 5 déc. 2014 à 08:45, Jeroen Ooms jeroen.o...@stat.ucla.edu a écrit :
Does Rcpp provide some elegant way to let the R user manage persistent
c++ objects that have no R type (e.g. internal handles or sessions of
some sort)?
In C, I would use R_MakeExternalPtr to create a ptr SEXP that the user
can pass from one R function to another. This also makes it easy to
add a finalizer with R_RegisterCFinalizerEx so that the garbage
collector will automatically clean up the session/handle whenever user
deletes the R object.
Most Rcpp examples I have seen use function arguments with standard
data types that are automatically mapped to R types. Does Rcpp have
any special mechanics for managing external objects (pointers) from R
which do not map to a SEXP type? Or do I have to fall back on
Rinternals for this?
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Returning an arma vec
Something like this:
template typename T
inline wrap( const arma::subview_coldouble x ){
return wrap( arma::MatT( x ) ) ;
}
(untested)
This would still wrap it as a matrix though as this is what subview_col
conceptually gives.
The only downside is that this is somewhat inefficient as it would have to
allocate memory for a arma::mat first and then copy that across to an
Rcpp::Matrix …
Romain
Le 3 déc. 2014 à 22:41, Martyn Plummer plumm...@iarc.fr a écrit :
You just need to put a new template specialization of wrap for the
subview_col class in RcppArmadilloWrap.h based on the existing one for the
subview class. And throw in one for subview_row for good measure.
Martyn
From: rcpp-devel-boun...@lists.r-forge.r-project.org
[rcpp-devel-boun...@lists.r-forge.r-project.org] on behalf of Dirk
Eddelbuettel [e...@debian.org]
Sent: 03 December 2014 19:25
To: Romain Francois
Cc: rcpp-devel@lists.r-forge.r-project.org
Subject: Re: [Rcpp-devel] Returning an arma vec
On 3 December 2014 at 18:30, Romain Francois wrote:
| 2. If we replace the lines marked // x with
|
|return wrap(x.subvec(1, 2));
|
| then it fails with a compiler error.
|
| error: cannot convert 'const arma::subview_coldouble' to 'SEXP' in
| initialization
|
| This should be easy/trivial to fix for someone with the right skills.
Sure. Maybe Gabor wants to give it a try.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
---
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify
the sender and delete it. Since its integrity cannot be guaranteed,
its content cannot involve the sender's responsibility. Any misuse,
any disclosure or publication of its content, either whole or partial,
is prohibited, exception made of formally approved use
---
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Const correctness of NumericVector iterators
And now sent a pull request. Not sure this will be merged in with the new
commandment that « Thou shalt not break abi ».
See: https://github.com/RcppCore/Rcpp/pull/211
Romain
Le 29 nov. 2014 à 13:52, Romain François rom...@r-enthusiasts.com a écrit :
Promoted this to an issue on github.
https://github.com/RcppCore/Rcpp/issues/209
Should not be very hard to fix, but this is indeed a bug. The code should not
compile if Rcpp respected const correctness.
Le 26 nov. 2014 à 14:20, Martyn Plummer plumm...@iarc.fr a écrit :
This is related to David Shih's thread about modifying input arguments
but I think it needs its own thread.
I found a problem when I tried porting some Rcpp code to run outside of
Rcpp by providing my own NumericVector implementation based on STL
vectors. In Rcpp it is possible to obtain a non-constant iterator for a
constant vector, whereas STL does not allow this.
In particular, it is possible to modify a const NumericVector. The
compiler allows this because the actual contents of the NumericVector
are in auxiliary memory. But this breaks the abstraction of the
NumericVector class.
An example is given below. The sumsquares function calculates the sum
of squares of a vector. Internally, it calls the workhorse function,
which is declared to take a constant reference as an argument. So it
looks safe to pass the input vector to workhorse without copying.
However the implementation of workhorse does in fact alter the vector.
### BEGIN SS.cc
#include Rcpp.h
using Rcpp::NumericVector;
static double workhorse(NumericVector const v);
// [[Rcpp::export]]
double sumsquares(NumericVector v)
{
//Since workhorse takes a constant reference we think we do not need
//to copy v...
return workhorse(v);
}
double workhorse(NumericVector const v)
{
double y = 0;
for (NumericVector::iterator i = v.begin(); i != v.end(); ++i) {
double x = *i;
//... but this function does alter its argument
x *= x;
y += x;
}
return y;
}
### END SS.cc
In R we have
library(Rcpp)
sourceCpp(SS.cc)
x - c(1,2,3)
sumsquares(x)
[1] 14
x #is modified
[1] 1 4 9
Martyn
---
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify
the sender and delete it. Since its integrity cannot be guaranteed,
its content cannot involve the sender's responsibility. Any misuse,
any disclosure or publication of its content, either whole or partial,
is prohibited, exception made of formally approved use
---
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Const correctness of NumericVector iterators
Promoted this to an issue on github. https://github.com/RcppCore/Rcpp/issues/209
Should not be very hard to fix, but this is indeed a bug. The code should not
compile if Rcpp respected const correctness.
Le 26 nov. 2014 à 14:20, Martyn Plummer plumm...@iarc.fr a écrit :
This is related to David Shih's thread about modifying input arguments
but I think it needs its own thread.
I found a problem when I tried porting some Rcpp code to run outside of
Rcpp by providing my own NumericVector implementation based on STL
vectors. In Rcpp it is possible to obtain a non-constant iterator for a
constant vector, whereas STL does not allow this.
In particular, it is possible to modify a const NumericVector. The
compiler allows this because the actual contents of the NumericVector
are in auxiliary memory. But this breaks the abstraction of the
NumericVector class.
An example is given below. The sumsquares function calculates the sum
of squares of a vector. Internally, it calls the workhorse function,
which is declared to take a constant reference as an argument. So it
looks safe to pass the input vector to workhorse without copying.
However the implementation of workhorse does in fact alter the vector.
### BEGIN SS.cc
#include Rcpp.h
using Rcpp::NumericVector;
static double workhorse(NumericVector const v);
// [[Rcpp::export]]
double sumsquares(NumericVector v)
{
//Since workhorse takes a constant reference we think we do not need
//to copy v...
return workhorse(v);
}
double workhorse(NumericVector const v)
{
double y = 0;
for (NumericVector::iterator i = v.begin(); i != v.end(); ++i) {
double x = *i;
//... but this function does alter its argument
x *= x;
y += x;
}
return y;
}
### END SS.cc
In R we have
library(Rcpp)
sourceCpp(SS.cc)
x - c(1,2,3)
sumsquares(x)
[1] 14
x #is modified
[1] 1 4 9
Martyn
---
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify
the sender and delete it. Since its integrity cannot be guaranteed,
its content cannot involve the sender's responsibility. Any misuse,
any disclosure or publication of its content, either whole or partial,
is prohibited, exception made of formally approved use
---
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Bug in loadRcppClass/loadModule?
sourceCpp knows how to deal with modules, i.e.:
inc - '
#include Rcpp.h
using namespace Rcpp;
double norm( double x, double y ) {
return sqrt( x*x + y*y );
}
RCPP_MODULE(mod) {
function( norm, norm );
}'
sourceCpp( code = inc )
giving:
norm( 3, 3 )
[1] 4.242641
Romain
Le 19 nov. 2014 à 05:49, Aaron Polhamus aaronpolha...@gmail.com a écrit :
Dear list,
In the process of writing a comprehensive unit testing application for Rcpp I
may have come across a bug in the code. It seems to me that the following
block should execute just fine, exporting the C++ class norm to the global
environment:
require(inline)
require(Rcpp)
inc - '
using namespace Rcpp;
double norm( double x, double y ) {
return sqrt( x*x + y*y );
}
RCPP_MODULE(mod) {
function( norm, norm );
}'
fx - cxxfunction(signature(), plugin=Rcpp, include=inc)
mod - Module(mod, getDynLib(fx))
loadRcppClass('norm', 'norm', mod)
What happens, though, is that the following error is returned:
Error in as.environment(pos) :
no item called moduleName on the search list
Digging in to loadRcppClass, I find that the function fails at the line:
mod - loadModule(module, NULL, env = where, loadNow = TRUE)
Entering loadModule, the function fails here, at the get statement:
loadM - as.environment(module)
module - get(loadM, moduleName)
Isn't this backward? get syntax is:
get(x, pos = -1, envir = as.environment(pos), mode = any,
inherits = TRUE)
Where x is the object sought in the specified environment. In this case,
the function is failing because it can't find moduleName in the environment's
search list, but the reason for this seems to be that the current statement
is search for an environment within a character string, rather than a
character string representing a named object within an environment.
Is this in need of a patch, or am I missing something obvious?
Cheers,
Aaron
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] tracking volatile bug
Le 18 nov. 2014 à 14:42, Serguei Sokol serguei.so...@gmail.com a écrit : Hi everybody, I am facing a volatile bug which appears and disappears in identical calls on identical data. My RcppArmadilla code is expm_cpp() (it is obtained by rex2arma tool which I have presented before, cf. attached file). It is compared and benchmarked vs its R counterpart expm.higham() (also attached). Both are computing matrix exponential by a same particular method. The results are identical for R and Rcpp on small and medium sized matrices nxn n=10:100 but on large matrices (n 800) various error messages can interrupt (or not) a normal run of expm_cpp(). Sometimes message says (in French) type 'char' indisponible dans 'eval', I suppose in English it must be unimplemented type 'char' in 'eval' I have seen (thanks to Google) a similar error message in the following snippet: /* call this R command: source(FileName) */ int errorOccurred; SEXP e = lang2(install(source), mkString(FileName)); /* mkChar instead of mkString would lead to this runtime error: * Error in source(FileName) : unimplemented type 'char' in 'eval' */ R_tryEval(e, R_GlobalEnv, errorOccurred); e is not protected here. Does the problem go away if you protect it: SEXP e = PROTECT( lang2(install(source), mkString(FileName))) ; Or more R/C++ idiomatically, which is both nicer and safer. Language e( source, FileName ) ; Romain which suggests that somewhere in Rcpp or RcppArmadillo there is a mkChar() call instead of mkString(). Other times, error message can say something like argument type[1]='x' must be one of 'M','1','O','I','F' or 'E' or argument type[1]='character' must be a one-letter character string This latter message is somewhat volatile per se. The part of message just after type[1]= can be 'character' (as above) or 'method' or 'ANY' etc. That kind of problem usually is related to premature GC. I have found these messages in the Matrix package https://r-forge.r-project.org/scm/viewvc.php/pkg/Matrix/src/Mutils.c?view=markuproot=matrixpathrev=2614 function char La_norm_type(const char *typstr) Seemingly, the argument *typstr is getting corrupted somewhere on the road. It is useless to say that debugging is of no help here. If run in a debugger, the program stops normally with or without error messages cited above. I have also tried to low the level of gcc optimization both in compiling R and the Rcpp code but it didn't help. Anybody has an experience in tracking down similar cases? This example can be run as: library(expm) library(Rcpp) source(expm_cpp.R) source(expm.higham.R) n=1000 As=matrix(rnorm(n*n), n) stopifnot(diff(range(expm.higham(As, balancing=TRUE)-expm_cpp(As, balancing=TRUE))) 1.e-14) The last command may be run several times before an error shows up. Cheers, Serguei. expm_cpp.Rexpm.higham.R___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Template and non-template arguments in RCPP_RETURN_VECTOR
Hi,
I guess RCPP_RETURN_VECTOR could be easily extended to support variadic number
of arguments, using either variadic templates or variadic macros.
https://github.com/RcppCore/Rcpp/blob/3ef9e662d89ebcfe71734675071568302bf10104/inst/include/Rcpp/macros/dispatch.h#L44
RCPP_RETURN_VECTOR is not that used as it looks kind of ugly and forces on you
dispatch on all the SEXP types and sometimes you just want say INTSXP and
REALSXP ...
Romain
Le 20 août 2014 à 14:30, Sven E. Templer sven.temp...@gmail.com a écrit :
To create a templated function one can use the macro RCPP_RETURN_VECTOR, e.g:
sourceCpp(code='
#include Rcpp.h
template typename T
T index_template ( T X )
{
Rcpp::IntegerVector I(1, 0);
return X[I];
}
// [[Rcpp::export]]
SEXP index ( SEXP X )
{
RCPP_RETURN_VECTOR(index_template, X);
}
')
index(letters)
index(c(pi,2,1))
Using a templated and a non-templated argument does not(?) allow use
of the macro, e.g.:
sourceCpp(code='
#include Rcpp.h
template typename T
T index2_template ( T X, Rcpp::IntegerVector I )
{
return X[I];
}
// [[Rcpp::export]]
SEXP index2 ( SEXP X, Rcpp::IntegerVector I )
{
switch(TYPEOF(X)) {
case STRSXP: return index2_template(Rcpp::VectorSTRSXP(X), I); break;
case REALSXP: return index2_template(Rcpp::VectorREALSXP(X), I); break;
case INTSXP: return index2_template(Rcpp::VectorINTSXP(X), I); break;
default: Rf_error(Unsupported type.);
}
}
')
index2(c(pi,2,1),2)
index2(letters,2)
Is there an easier way that I am missing, than to use switch/TYPEOF ...?
Like RCPP_RETURN_VECTOR2(index_template, X, I).
Thank you for any hint,
Sven.
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] (Very) rare segfault
This would be typical gc problems. Could be anywhere. Even if you run it through gdb, the problem will incubate for some time before showing symptoms. We’ve been lucky sometimes to fix some of these by accident, but it is otherwise pretty hard. Romain Le 20 août 2014 à 19:38, Gregor Kastner gregor.kast...@wu.ac.at a écrit : Dear all, during a large simulation study on around 300 cores, I have just noticed strange behavior of my package depending on Rcpp. Strange in the sense that on very rare occasions (around 1 in 10 function calls through .Call), a NumericMatrix object created at C level and returned back to R as part of a list isn't available there, causing a memory not mapped segfault when trying to access it from R. The issue is not deterministically reproducible and, as mentioned, very rare. This makes narrowing down the bug a pain. I do know however that this problem does not appear in Rcpp 0.10.5 but does appear in Rcpp 0.11.0. Maybe there is anyone out there who has experienced something similar or otherwise has a hunch where I should dig further. Thanks a ton in advance, Gregor ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
Sent a PR. Everything was pretty well explained in the original email. Le 29 juil. 2014 à 13:51, Dirk Eddelbuettel e...@debian.org a écrit : On 29 July 2014 at 12:17, Christian Authmann wrote: | Sorry, due to a restrictive firewall on my dev computer, I cannot access | github from it. A mail will have to suffice for now. Can you email me a proper patch, created the usual way via diff -u, or git diff ? Thanks, Dirk ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Using spatstat in Rcpp
Hello,
You seem to be confusing R namespaces and C++ namespaces and assuming you can
call an R function as if it belonged to a C++ namespace.
R functions and c++ functions are different things.
You can do something like:
// get the spatstat environment
Environment spatstat( package:spatstat ) ;
// get the discpartarea function from that env
Function discpartarea = spatstat[discpartarea];
Then you can call discpartarea.
Romain
Le 11 juin 2014 à 19:01, mohammad ghorbani ghorbani...@yahoo.com a écrit :
Hi there,
I would like to call discpartarea() and as.owin() functions of spatstat from
Rcpp. In a simple example
consider the following C++ code in which I'm trying to access the above
functions:
#include Rcpp.h
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector IndepSelfCortCpp( NumericMatrix obsu) {
NumericMatrix obsxy = obsu( _ , Range(1,2) ) ;
NumericVector xyW= NumericVector::create(0,56,0,38);
double rslt = 0;
rslt= spatstat::discpartarea(obsxy, 0.1, spatstat::as.owin(xyW));
return (rslt);
}
/* ** R
obsu - matrix(c(0.5, 1.5, 4, 12, 1,2,3,4,2,3,5,7), ncol=3)
IndepSelfCortCpp(obsu)
*/
When I source the file in Rstudio with sourceCpp(), I get the error:
'spatstat' has not been declard
I was wondering, a direct call a function of an R package like spatstat is
possible from Rcpp.
If yes, Could anyone help me on debugging the code?
Best Regards,
Mohammad Ghorbani
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Speed up of the data.frame creation in DataFrame.h
Le 7 juin 2014 à 03:27, Dmitry Nesterov dmitry.neste...@gmail.com a écrit :
Hello,
Here I report the slowness in creation of Rcpp DataFrame objects and proposed
change to speed it up.
For system information, here is output from sessionInfo():
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin13.1.0 (64-bit)
...
other attached packages:
[1] microbenchmark_1.3-0 Rcpp_0.11.1
I am using Rcpp package to port my old functions written with R's C interface
to a more convenient style of Rcpp.
While writing code that creates data.frame’s, I noticed that the Rcpp-based
code was running quite a bit slower (using microbenchmark package) than my
old implementation. The difference was approximately 40(!) times slower for
data frame 50x2 (row x col)
I have narrowed the speed difference down to the following call:
return Rcpp::DataFrame::create(Rcpp::Named(“xdata”)=x,
Rcpp::Named(“ydata”)=y);
Where x and y are Rcpp::NumericVector objects.
By debugging through the code and Rcpp, I noticed that during the creation
Rcpp uses “as.data.frame” conversion on the vector list that contained x, y
vectors and their names “xdata” and “ydata”, while this step was not
necessary in my previous code using C interface.
Well, how then do you guarantee that the data frame is not corrupt ?
Consider this code:
#include Rcpp.h
using namespace Rcpp ;
// [[Rcpp::export]]
DataFrame test(){
NumericVector x = NumericVector::create( 1, 2, 3, 4 ) ;
NumericVector y = NumericVector::create( 1, 2 ) ;
return DataFrame::create(_[x] = x, _[y] = y ) ;
}
The benefit of calling as.data.frame is that it would handle recycling y
correctly.
Just setting the class attribute to data.frame by brute force would make a
corrupt data frame. Perhaps you can get your suggestion approved on the basis
of being consistent with other ways to get corrupt data frames in Rcpp.
https://github.com/RcppCore/Rcpp/issues/144
The basic idea is valid, but this would need more work and understanding of the
conceptual requirements of a data frame.
Romain
In Rcpp/DataFrame.h:87
static DataFrame_Impl from_list( Parent obj ){
This in turn calls on line 104:
return DataFrame_Impl(obj) ;
and which ultimately calls on line 78:
void set__(SEXP x){
if( ::Rf_inherits( x, data.frame )){
Parent::set__( x ) ;
} else{
SEXP y = internal::convert_using_rfunction( x, as.data.frame
) ;
Parent::set__( y ) ;
}
}
Since the DataFrame::create() function has not set a class attribute to
“data.frame” by far, the conversion “as.data.frame” takes place and slows
down the creation of the final object.
I propose to make change on line 103 to set class attribute to “data.frame”,
so no further conversion will take place:
if( use_default_strings_as_factors ) {
Rf_setAttrib(obj, R_ClassSymbol, Rf_mkString(data.frame));
return DataFrame_Impl(obj) ;
}
I tested it and it brought the speed of execution of the function to about
the same as it was before with plain C API.
Please let me know if it makes sense or maybe I should use
DataFrame::create() function differently.
Best,
Dmitry
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Speed up of the data.frame creation in DataFrame.h
Hello,
I was merely pointing out the problem. People who maintain and contribute to
Rcpp will tell you what they expect. I am no longer one of them. So I don’t
really care either way, unless it starts adding a bug that will cause issues
for software I’m involved with that still has to depend on Rcpp for reasons out
of my control.
On a general note, I’d argue that it makes sense to submit the pull request
anyway as it creates a special place where you can discuss the proposal, and it
triggers continuous testing, so that travis will tell you if you break
something.
Romain
Le 7 juin 2014 à 14:35, Dmitry Nesterov dmitry.neste...@gmail.com a écrit :
Hello Romain,
maybe then another function, like force_create() could be available? Or some
checks for equal number of elements in each vector.
One of the main Rcpp advantages to the user is its flexibility and speed,
compared to the plain R code.
I am not sure at this point what solution would be the best, but having fast
methods in Rcpp would be really great.
Should I wait then before submitting the pull request?
Dmitry
On Jun 7, 2014, at 7:21 AM, Romain François rom...@r-enthusiasts.com wrote:
Le 7 juin 2014 à 03:27, Dmitry Nesterov dmitry.neste...@gmail.com a écrit :
Hello,
Here I report the slowness in creation of Rcpp DataFrame objects and
proposed change to speed it up.
For system information, here is output from sessionInfo():
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin13.1.0 (64-bit)
...
other attached packages:
[1] microbenchmark_1.3-0 Rcpp_0.11.1
I am using Rcpp package to port my old functions written with R's C
interface to a more convenient style of Rcpp.
While writing code that creates data.frame’s, I noticed that the Rcpp-based
code was running quite a bit slower (using microbenchmark package) than my
old implementation. The difference was approximately 40(!) times slower for
data frame 50x2 (row x col)
I have narrowed the speed difference down to the following call:
return Rcpp::DataFrame::create(Rcpp::Named(“xdata”)=x,
Rcpp::Named(“ydata”)=y);
Where x and y are Rcpp::NumericVector objects.
By debugging through the code and Rcpp, I noticed that during the creation
Rcpp uses “as.data.frame” conversion on the vector list that contained x, y
vectors and their names “xdata” and “ydata”, while this step was not
necessary in my previous code using C interface.
Well, how then do you guarantee that the data frame is not corrupt ?
Consider this code:
#include Rcpp.h
using namespace Rcpp ;
// [[Rcpp::export]]
DataFrame test(){
NumericVector x = NumericVector::create( 1, 2, 3, 4 ) ;
NumericVector y = NumericVector::create( 1, 2 ) ;
return DataFrame::create(_[x] = x, _[y] = y ) ;
}
The benefit of calling as.data.frame is that it would handle recycling y
correctly.
Just setting the class attribute to data.frame by brute force would make a
corrupt data frame. Perhaps you can get your suggestion approved on the
basis of being consistent with other ways to get corrupt data frames in
Rcpp.
https://github.com/RcppCore/Rcpp/issues/144
The basic idea is valid, but this would need more work and understanding of
the conceptual requirements of a data frame.
Romain
In Rcpp/DataFrame.h:87
static DataFrame_Impl from_list( Parent obj ){
This in turn calls on line 104:
return DataFrame_Impl(obj) ;
and which ultimately calls on line 78:
void set__(SEXP x){
if( ::Rf_inherits( x, data.frame )){
Parent::set__( x ) ;
} else{
SEXP y = internal::convert_using_rfunction( x,
as.data.frame ) ;
Parent::set__( y ) ;
}
}
Since the DataFrame::create() function has not set a class attribute to
“data.frame” by far, the conversion “as.data.frame” takes place and slows
down the creation of the final object.
I propose to make change on line 103 to set class attribute to
“data.frame”, so no further conversion will take place:
if( use_default_strings_as_factors ) {
Rf_setAttrib(obj, R_ClassSymbol, Rf_mkString(data.frame));
return DataFrame_Impl(obj) ;
}
I tested it and it brought the speed of execution of the function to about
the same as it was before with plain C API.
Please let me know if it makes sense or maybe I should use
DataFrame::create() function differently.
Best,
Dmitry
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] table, rev and missing names
Hello,
You pretty much have to do this manually. rev is part of Rcpp sugar. Defined
here:
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/sugar/functions/rev.h
It does not preserve names. That’s by design. It would have been very difficult
to do it automatically, i.e. what happens here: rev( x * y ), etc … it is hard
to decide which names to propagate, harder to try to follow R rules about it,
and even harder to implement.
So if you want names, you have to handle them yourself.
Romain
Le 6 juin 2014 à 12:58, Sven E. Templer sven.temp...@gmail.com a écrit :
Hi,
consider this code:
require(Rcpp)
require(inline)
t - cxxfunction(sig=c(xx=character), plugin=Rcpp, body='
CharacterVector x(xx);
IntegerVector t = table(x);
return t;')
r - cxxfunction(sig=c(xx=character), plugin=Rcpp, body='
CharacterVector x(xx);
IntegerVector t = table(x);
IntegerVector r = rev(t);
return r;')
o - cxxfunction(sig=c(xx=character), plugin=Rcpp, body='
CharacterVector x(xx);
IntegerVector t = table(x);
CharacterVector n = t.names();
IntegerVector r = rev(t);
r.names() = rev(n);
return r;')
t(c('a','a','b',NA))
r(c('a','a','b',NA))
o(c('a','a','b',NA))
Reversed vectors loose their name ( t() vs r() ) and have to be copied
and reversed 'manually' ( as in o() ). Is rev() a function declared by
Rcpp, if so can names be reserved while reverting or is there any
other easier solution than in o() ?
Thank you!
Sven
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp release candidate
Watch out for this part:
Le 5 juin 2014 à 15:05, Gabor Grothendieck ggrothendi...@gmail.com a écrit :
installing to C:/Users/Gabor/Documents/R/win-library/3.1/Rcpp/libs/x64
Warning in file.copy(files, dest, overwrite = TRUE) :
problem copying .\Rcpp.dll to
C:\Users\Gabor\Documents\R\win-library\3.1\Rcpp\libs\x64\Rcpp.dll:
Permission denied
I guess you tried to install from github while Rcpp was already loaded in your
R session, so it has not really been installed.
Romain
** R
** inst
** tests
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
*** arch - i386
*** arch - x64
* DONE (Rcpp)
code - '
+ // [[Rcpp::plugins(cpp11)]]
+ #include Rcpp.h
+ #include boost/range/irange.hpp
+ using boost::irange;
+ // [[Rcpp::depends(BH)]]
+ // [[Rcpp::export]]
+ int useCpp11() {
+ auto sum(0);
+ for(const auto i : irange(0,4)) { sum += i; }
+ return sum;
+ }
+ '
library(Rcpp)
sourceCpp(code = code, rebuild = TRUE)
useCpp11()
[1] 6
R.version.string
[1] R version 3.1.0 Patched (2014-05-09 r65562)
On Thu, Jun 5, 2014 at 4:21 AM, JJ Allaire jj.alla...@gmail.com wrote:
I couldn't reproduce this on Windows 7 with R 3.1 (which should have been
using USE_CXX1X=yes under the hood resulting in -std=c++0x passed to gcc).
However, I have this change which should make the cpp11 plugin automatically
pass -std=c++0x when on R = 3.0:
https://github.com/RcppCore/Rcpp/pull/148
Does that work for you? You can install with:
devtools::install_github(RcppCore/Rcpp, ref = feature/windows-c++0x)
On Thu, Jun 5, 2014 at 3:36 AM, Gabor Grothendieck ggrothendi...@gmail.com
wrote:
On Wed, Jun 4, 2014 at 11:21 PM, Dirk Eddelbuettel e...@debian.org wrote:
Rcpp 0.11.2 should be ready.
If anybody wants to jump in and do last minute testing, please do so
now.
I ran two complete tests against CRAN last weekend, the results are
summarized as usual in the GitHub repo at
https://github.com/RcppCore/rcpp-logs
Of 215 CRAN packages, all but 18 passed. Of those 18 a number where due
to
package sirt not building because ... I use FC='ccache gfortran' which
is not
gfortran so its configure failed. Grrr. I would pass next time.
Anyway, 195 packages passed just fine, so we should be good. But if
there is
something anyone of you would like to test, now would be a good time as
I may
upload the current version to CRAN in the next few days unless I hear
objections.
There seems to be a problem using Rcpp::plugins(cpp11) on Windows
8.1. It gives the error:
cc1plus.exe: error: unrecognized command line option '-std=c++11'
I am using Rtools 3.1.0.1942 (which is the latest version) and for
that it needs -std=c++0x or -std=gnu++0x
If I remove the plugins line and instead issue this line first then it
all works (except as per prior email I built Rcpp without vignettes to
get around that problem):
Sys.setenv(PKG_CXXFLAGS=-std=c++0x) # for gcc 4.6.3
code - '
+ // [[Rcpp::plugins(cpp11)]]
+
+ #include Rcpp.h
+ #include boost/range/irange.hpp
+
+ using boost::irange;
+
+ // [[Rcpp::depends(BH)]]
+
+ // [[Rcpp::export]]
+ int useCpp11() {
+ auto sum(0);
+ for(const auto i : irange(0,4)) { sum += i; }
+ return sum;
+ }
+ '
library(Rcpp)
sourceCpp(code = code)
g++ -m64 -IC:/PROGRA~1/R/R-3.1/include -DNDEBUG
-IC:/Users/Gabor/Documents/R/win-library/3.1/Rcpp/include
-IC:/Users/Gabor/Documents/R/win-library/3.1/BH/include
-Id:/RCompile/CRANpkg/extralibs64/local/include -std=c++11-O2
-Wall -mtune=core2 -c file18a42f7f546e.cpp -o file18a42f7f546e.o
cc1plus.exe: error: unrecognized command line option '-std=c++11'
make: *** [file18a42f7f546e.o] Error 1 Warning message: running
command 'make -f C:/PROGRA~1/R/R-3.1/etc/x64/Makeconf -f
C:/PROGRA~1/R/R-3.1/share/make/winshlib.mk
SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)'
SHLIB=sourceCpp_83768.dll WIN=64 TCLBIN=64
OBJECTS=file18a42f7f546e.o' had status 2
Error in sourceCpp(code = code) :
Error 1 occurred building shared library.
useCpp11()
Error: could not find function useCpp11
sourceCpp(code = code, verbose = TRUE)
Generated extern C functions
#include Rcpp.h
RcppExport SEXP sourceCpp_37333_useCpp11() {
BEGIN_RCPP
SEXP __sexp_result;
{
Rcpp::RNGScope __rngScope;
int __result = useCpp11();
PROTECT(__sexp_result = Rcpp::wrap(__result));
}
UNPROTECT(1);
return __sexp_result;
END_RCPP
}
Generated R functions
---
`.sourceCpp_37333_DLLInfo` -
dyn.load('C:/Users/Gabor/AppData/Local/Temp/RtmpmUpJdX/sourcecpp_18a41e263c3c/sourceCpp_77519.dll')
useCpp11 - Rcpp:::sourceCppFunction(function() {}, FALSE,
`.sourceCpp_37333_DLLInfo`,
Re: [Rcpp-devel] Converting std::cout to Rcpp::Rcout automatically
Hi, I used to redirect std::cout to Rcpp::Rcout back when I still had Rcout in Rcpp11. e.g. https://github.com/Rcpp11/Rcpp11/blob/22cc410ea87a2668e547acf6510d07ca812dfca8/src/Rcpp11_init.cpp Which was basically leveraging std::cout.rdbuf. A variant of http://stackoverflow.com/questions/10150468/how-to-redirect-cin-and-cout-to-files And then just using std::cout; Of course then you get CRAN complaining. Romain Hi, dear all, I am using Rcpp to integrate an available C++ library with R. Since the std::cout and std::cerr are not permitted when uploading to CRAN, I have to modify files manually. It will be somewhat laborious if the library Does anyone have any idea how can I do that automatically? Thank you! Best, KK -- Qiang Kou q...@umail.iu.edu School of Informatics and Computing, Indiana University ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Not able to convert from Rcpp::NumericVector to Teuchos::ArrayRCPsize_t
Hello,
From what I understand of ArrayRCP, having read the documentation for a few
minutes.
(http://trilinos.sandia.gov/packages/docs/r9.0/packages/teuchos/doc/html/classTeuchos_1_1ArrayRCP.html)
This looks like a vector and therefore it is likely that the default
ExporterT will not be useful as it tries to use the constructor taking a SEXP
:
template typename T
class Exporter{
public:
Exporter( SEXP x ) : t(x){}
inline T get(){ return t ; }
private:
T t ;
} ;
you can use a RangeExporter instead which looks more compatible to what
ArrayRCP looks like:
template typename T class RangeExporter {
public:
typedef typename T::value_type r_export_type ;
RangeExporter( SEXP x ) : object(x){}
~RangeExporter(){}
T get(){
T vec( ::Rf_length(object) );
::Rcpp::internal::export_range( object, vec.begin() ) ;
return vec ;
}
private:
SEXP object ;
} ;
You can probably do this by having something like this early enough (after
RcppCommon.h but before Rcpp.h).
namespace Rcpp {
namespace traits {
template typename T class Exporter Teuchos::ArrayRCPT : public
RangeExporter Teuchos::ArrayRCPT {
public:
Exporter( SEXP x) : RangeExporter Teuchos::ArrayRCPT (x){}
}
}
}
Romain
Le 23 mai 2014 à 00:42, Chaomei Lo chaome...@gmail.com a écrit :
Sorry to confuse you, Dirk, I had my previous message title wrong. Here
below was the message with the correct title and content.
I have created R packages using Makevars and it works pretty good for me. I
am able to convert from a Rcpp::NumericVector to std::vector as in below.
NumericVector col_cts = buildMatrix(Xr);
vectorlong unsigned int col_counts = Rcpp::asvectorlong unsigned
int(col_cts);
Now I am having a problem with an application involves the Trilinos library.
Here below I am trying to convert a Rcpp::NumericVector to
Teuchos::ArrayRCPsize_t in the following line, it gave me errors as shown
below in red. Would you please help me with this ?
Teuchos::ArrayRCPsize_t
col_counts=Rcpp::asTeuchos::ArrayRCPsize_t(col_cts);
Thanks a lot.
In file included from
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/as.h:25:0,
from
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/RcppCommon.h:169,
from
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp.h:27,
from buildMatrix.cpp:4:
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/internal/Exporter.h: In
constructor 'Rcpp::traits::ExporterT::Exporter(SEXP) [with T =
Teuchos::Array
RCPlong unsigned int, SEXP = SEXPREC*]':
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/as.h:79:51:
instantiated from 'T Rcpp::internal::as(SEXP,
Rcpp::traits::r_type_generic_tag) [with T =
Teuchos::ArrayRCPlong unsigned int, SEXP = SEXPREC*]'
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/as.h:144:84:
instantiated from 'T Rcpp::as(SEXP) [with T = Teuchos::ArrayRCPlong unsigned
int, SEXP
= SEXPREC*]'
buildMatrix.cpp:84:87: instantiated from here
/share/apps/R/3.0.2/lib64/R/library/Rcpp/include/Rcpp/internal/Exporter.h:31:31:
error: invalid conversion from 'SEXP' to 'long int' [-fpermissive]
/people/d3j508/trilinos-11.6.1/trilinos-11.6.1_Install/include/Teuchos_ArrayRCP.hpp:129:1:
error: initializing argument 1 of 'Teuchos::ArrayRCPT::ArrayRC
P(Teuchos::ArrayRCPT::size_type, const T) [with T = long unsigned int,
Teuchos::ArrayRCPT::size_type = long int]' [-fpermissive]
make: *** [buildMatrix.o] Error 1
ERROR: compilation failed for package 'Tpkg'
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] bigmatrix and segmentation fault due to 'memory not mapped'
Le 15 mai 2014 à 09:03, Stefano Calza steca...@gmail.com a écrit :
Hi everybody,
I am trying to use big.matrix from Rcpp basically to write some (integer)
data to a matrix.
I keep getting segmentation fault due to 'memory not mapped'.
Debugging with gdb I found out that the critical point is
MatrixAccessorint ma(*pBigMat);
The function is declared as something like (I just followed the Gallery Rcpp
example):
RcppExport SEXP myFun(SEXP X, SEXP Y, SEXP Z, SEXP XX, XPtrBigMatrix
pBigMat)
Basically it cannot get to the correct pointer.
The really weird thing is that this error happens ONLY using the function
built within a package
.Call('myFun',X,Y,Z,XX,bigMat@address,package='myPackage')
BUT if I use the very same code, changing just the declaration
// [Rcpp::export]
IntegerVector myFun(SEXP X, SEXP Y, SEXP Z, SEXP XX, XPtrBigMatrix pBigMat)
and then
sourceCpp('mycode.cpp')
and
myFun(X,Y,Z,XX,bigMat@address)
it works fine!
So what am I doing wrong here? Is the pointer reset somehow? But why only
when using .Call version?
Thanks
Stefano
If you use a raw .Call, all your parameters have to be SEXP.
If you want to use other parameter types, such as XPtrBigMatrix, you need to
use attributes (i.e. sourceCpp or compileAttributes) so that it generates .Call
compatible function for you.
Romain
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp11 3.1.0 is on CRAN
Hello, (may contains traces of personal opinions) My motivation for starting Rcpp11 were: - Assuming C++11, which is nicer to use and teach. Rcpp still wants to be compatible with older standard, which essentially means that even if I write something new using C++11, I still have to figure out how to write the same thing in C++98. - modernize the code base. This meant let go of a few features so that we have what we keep better. This is incompatible with Rcpp’s maintainership policy. Last time I asked to remove a feature from Rcpp, I was told that it would take a year of deprecation. In Rcpp11, because I’m in charge I can decide to break stuff to make something better. Rcpp has been a great project to work on for me. I’ve learned a lot of C++, and I think I owe most of my C++ knowledge from involvement I have with Rcpp. But as far as I’m concerned, the string requirements take all the fun away. Working on Rcpp11 has brought fun back. I can innovate. There will always be some conceptual compatibility between Rcpp and Rcpp11. For example both have the NumericVector class to handle numeric vectors. However in that particular example, the implementation of NumericVector in Rcpp is too complicated, you have gazillion of constructors, etc ... hard to maintain, hard to document, hard to teach. Now that Rcpp11 can be used on current versions of OSX, recent enough linux, windows and even solaris (if you use gcc), what I would suggest is that you try it and come back with questions (not on this list though, please use the google group that is not strictly restricted to Rcpp questions). What might help you deciding is that in Rcpp11, we did not retain some features such as modules and date/time related classes. If your code uses these, then you should probably either stick with Rcpp or start motivating me for adding something along the lines in Rcpp11. There is still a need for something like modules, but not with this implementation. Now, as Dirk says, you can use C++11 with Rcpp. Just as much as you can use C++11 with vanilla .Call/.C. Personally I think the future of R and C++ is with Rcpp11. This is where I’ll focus my time. Romain Le 17 avr. 2014 à 08:24, Søren Højsgaard sor...@math.aau.dk a écrit : Dear all, My understanding is that Rcpp11 will employ features of c++11 (which is very nice) but other than that it is not clear to me how Rcpp and Rcpp11 relate to each other? Can I start to use Rcpp11 with my existing Rcpp-based packages or is Rcpp and Rcpp11 branching off in different directions? Cheers Søren -Original Message- From: rcpp-devel-boun...@lists.r-forge.r-project.org [mailto:rcpp-devel-boun...@lists.r-forge.r-project.org] On Behalf Of Romain Francois Sent: 11. april 2014 15:26 To: rcpp-devel@lists.r-forge.r-project.org Subject: [Rcpp-devel] Rcpp11 3.1.0 is on CRAN Hello, I'll keep it short here. Rcpp11 3.1.0 was released on CRAN today. An announcement email has been sent to both r-packages and the new R and C++ mailing list. https://groups.google.com/forum/#!forum/r-and-cpp Best Regards, Romain ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp11 3.1.0 is on CRAN
Le 17 avr. 2014 à 09:42, Hao Ye h...@ucsd.edu a écrit : Hi Romain, Thanks for the explanation -- I was curious about the difference between Rcpp and Rcpp11, as well. What might help you deciding is that in Rcpp11, we did not retain some features such as modules and date/time related classes. If your code uses these, then you should probably either stick with Rcpp or start motivating me for adding something along the lines in Rcpp11. There is still a need for something like modules, but not with this implementation. Does this mean that there will be some other mechanism for exposing c++ classes to R? Maybe in some way that supports inheritence? ;) Yes. Problems with Rcpp modules are: - the way you express things is limited by C++ grammar. It was fun and challenging to write it. But experience of teaching modules shows that the concepts are somewhat hard to grasp. - it is very demanding in terms of resources In the future, I’d like to look into code generation (a la attributes) as a mean of exposing classes. So we need something expressive enough. My current blue sky line of thinking about this is that I’d like to have some sort of intermediate language between R and C++. John has done something similar with the exposeClass in Rcpp. https://github.com/RcppCore/Rcpp/blob/master/R/exposeClass.R It goes in the right direction, but this time you are limited by R’s grammar. This has been on my radar for some time, but I think having a class system that is nice to use in R requires some grammatical changes. It is unlikely that I will have the leverage to change R’s grammar, but what I can work on is an intermediate language that generates R code. In any case, Rcpp11 still has the external pointer class template, so we can « write modules by hand ». Romain ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Distribution of Rcpp codebase
Le 8 avr. 2014 à 10:12, Xavier Robin xav...@cbs.dtu.dk a écrit : My 2 cents... On 07/04/14 10:12, Romain François wrote: It would also mean many copies of the same code base. To which I’m thinking: so what. No, it will mean many copies of /many different and mostly outdated/ code bases. Still: so what ;) You can count on me to forget to git pull next time I update my package. And as long as your package keeps working, this is not so much of an issue. You are then in control of which version of the codebase is used. If you want a new version of the codebase, you can get it, and the challenge for me is to make it easy enough for you to get and deploy it into your package, if you don’t that’s fine. Now consider the alternative. You have no idea of which version of the codebase is used with your package. You have no idea if the version used at runtime is the same as the version that was used when the package was compiled. When a new Rcpp package is released, you definitely have to recompile yours, and need to ask your users to recompile your package against this version. I prefer when I’m in control. What about something like the BH package that contains the boost headers? I'm using it in a project I'm working on, and just use a LinkingTo declaration with something in Makevars. That works fine because BH is truly header only. Rcpp is not. The change in Rcpp 0.11.0 was a big step forward, but it is a job half done. Functions in the .h files of Rcpp constantly poke into the Rcpp.so. Any binary change in Rcpp creates hard problem to fix. Currently the usual advice is to ask to recompile, etc ... It is really easy to make such a binary change. Of course ideally it would be in a build-depends type of declaration so it isn't pulled during binary installs. Xavier ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] Generic R and C++ discussion
Hello, I have created a new mailing list (as a google group) for general discussions about R and C++. https://groups.google.com/forum/#!forum/r-and-cpp Shame that it had to come to this, but apparently Rcpp-devel is only for discussing the Dirk approved implementation of Rcpp. Personally, I will keep watching Rcpp-devel, and I hope I can still contribute interesting answers here, but I will use the google group for broad discussions. Romain ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Distribution of Rcpp codebase
Le 8 avr. 2014 à 10:51, Rainer M Krug rai...@krugs.de a écrit : Martyn Plummer plumm...@iarc.fr writes: And another 2 cents from me. A package is the basic unit of functionality in R. Whatever functionality you are providing, I think a package is the best way to deliver it. There is a well developed framework for versioning, dependency resolution, testing, and distribution. If you choose some other mechanism, then I suspect that any developer problems you eliminate will just return as system administration problems. I thought I could keep out of this... rcpp... is so much the core of many packages, that the mechanism of packages really shows its shortcomings, namely the versioning. A different aspect was discussed on the r-devel list some time ago concerning snapshots of CRAN to provide reproducibility. The part which makes rcpp outstanding from other packages, is that it is used mainly during compilation and not that much during running - that is if I understand the header only concept correctly. Well with the current Rcpp, you still need the runtime for any of the functions that are registered here: https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp#L85 That’s what I meant earlier when I mentioned job half done. The intention of the change in 0.11.0 was to move away from runtime, but we did not go far enough. In contrast, as far as I know, all other packages provide run-time features as well as compile time - and this is what the packages were designed for - and I might say they work quite well. I agree. I can see Romain's point (oparticularly the more fine grained control of the developer), but I also understand that Dirk will keep rcpp as a package. Sure. My question is: would it be possible to combine these two, i.e. have one package, which contains different versions, and to use one command to switch between these? So one would have one package, which will switch between different versions? I see your point, but I would not want to do that. I can definitely foresee a whole new class of issues with this scenario. I don't know if this would be possible or a suitable solution? The other would obviously be to have different versions of rcpp on CRAN, similar to ggplot or oxygen. I can see this working. But there could be Rcpp_0_12_0, Rcpp_0_12_1, etc .. as different packages so that developers who want to update their package would need to change the version on which they depend. Not sure CRAN would be impressed if I start releasing a new package for each version. Cheers, Rainer Martyn On Tue, 2014-04-08 at 10:12 +0200, Xavier Robin wrote: My 2 cents... On 07/04/14 10:12, Romain François wrote: It would also mean many copies of the same code base. To which I’m thinking: so what. No, it will mean many copies of /many different and mostly outdated/ code bases. You can count on me to forget to git pull next time I update my package. What about something like the BH package that contains the boost headers? I'm using it in a project I'm working on, and just use a LinkingTo declaration with something in Makevars. Of course ideally it would be in a build-depends type of declaration so it isn't pulled during binary installs. Xavier ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Distribution of Rcpp codebase
Le 8 avr. 2014 à 11:47, Rainer M Krug rai...@krugs.de a écrit : Romain François rom...@r-enthusiasts.com writes: Le 8 avr. 2014 à 10:51, Rainer M Krug rai...@krugs.de a écrit : Martyn Plummer plumm...@iarc.fr writes: And another 2 cents from me. A package is the basic unit of functionality in R. Whatever functionality you are providing, I think a package is the best way to deliver it. There is a well developed framework for versioning, dependency resolution, testing, and distribution. If you choose some other mechanism, then I suspect that any developer problems you eliminate will just return as system administration problems. I thought I could keep out of this... rcpp... is so much the core of many packages, that the mechanism of packages really shows its shortcomings, namely the versioning. A different aspect was discussed on the r-devel list some time ago concerning snapshots of CRAN to provide reproducibility. The part which makes rcpp outstanding from other packages, is that it is used mainly during compilation and not that much during running - that is if I understand the header only concept correctly. Well with the current Rcpp, you still need the runtime for any of the functions that are registered here: https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp#L85 That’s what I meant earlier when I mentioned job half done. The intention of the change in 0.11.0 was to move away from runtime, but we did not go far enough. I must admit, I am not to familiar with rcpp to comment on these functions, but would it be possible to split Rcpp into headers-only, i.e. only for compiling and developing, and Rcpp-runtime for runtime? Because I really think it might make sense to have additional function at runtime? They are really too tightly coupled for that. I’ve been through making Rcpp11 truly header only and it was really hard. It was worth every second of it, but still hard. Doing it for Rcpp is impossible, at least with Dirk’s maintainer requirements. In contrast, as far as I know, all other packages provide run-time features as well as compile time - and this is what the packages were designed for - and I might say they work quite well. I agree. I can see Romain's point (oparticularly the more fine grained control of the developer), but I also understand that Dirk will keep rcpp as a package. Sure. My question is: would it be possible to combine these two, i.e. have one package, which contains different versions, and to use one command to switch between these? So one would have one package, which will switch between different versions? I see your point, but I would not want to do that. I can definitely foresee a whole new class of issues with this scenario. I don't know if this would be possible or a suitable solution? The other would obviously be to have different versions of rcpp on CRAN, similar to ggplot or oxygen. I can see this working. But there could be Rcpp_0_12_0, Rcpp_0_12_1, etc .. as different packages so that developers who want to update their package would need to change the version on which they depend. Well - I would stick with the usual system, that would mean Rcpp_0_12, Rcpp_0_13, ... and no further fine grained. Same difference. I think this would be kind of confusing, but at least it would be allowed as « Rcpp » is not the same name as « Rcpp_0_12 ». As a side note, I plan to version Rcpp11 according to the version of R, so the first release of Rcpp11 will be version 3.1.0, ... Not sure CRAN would be impressed if I start releasing a new package for each version. Agreed. Cheers, Rainer Martyn On Tue, 2014-04-08 at 10:12 +0200, Xavier Robin wrote: My 2 cents... On 07/04/14 10:12, Romain François wrote: It would also mean many copies of the same code base. To which I’m thinking: so what. No, it will mean many copies of /many different and mostly outdated/ code bases. You can count on me to forget to git pull next time I update my package. What about something like the BH package that contains the boost headers? I'm using it in a project I'm working on, and just use a LinkingTo declaration with something in Makevars. Of course ideally it would be in a build-depends type of declaration so it isn't pulled during binary installs. Xavier ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33
Re: [Rcpp-devel] Error in Module
Hello,
Just sourceCpp the .cpp file and use the functions verbatim:
sourceCpp( /tmp/mod.cpp )
bar(2L)
[1] 4
If you really want to use the module as an object, you have to pick it up from
the right spot:
yada - Module(yada, where = tail(getLoadedDLLs(), 1)[[1]] )
yada$hello()
[1] hello
Romain
Le 8 avr. 2014 à 09:00, Brötje David d.broe...@tu-braunschweig.de a écrit :
Hello,
I want to expose a C++ class to R through Rcpp. For that I want to try out a
few examples from the note Exposing C++ functions and classes with Rcpp
modules and the book Seamless R and C++ Integration with Rpp. But I can't
manage to get them work. It ends up with an error. So this is what I'm doing.
First I create a cpp file with the c++ code from the example. The full
content of the cpp file is below.
#include Rcpp.h
using namespace Rcpp;
std::string hello() { return hello; }
int bar( int x) { return x*2; }
double foo( int x, double y) { return x*y; }
void bla( ) { Rprintf( hello\\n ); }
void bla1( int x) {
Rprintf( hello (x = %d)\\n, x );
}
void bla2( int x, double y) {
Rprintf( hello (x = %d, y = %5.2f)\\n, x, y );
}
RCPP_MODULE(yada) {
using namespace Rcpp;
function( hello , hello );
function( bar , bar );
function( foo , foo );
function( bla , bla );
function( bla1 , bla1 );
function( bla2 , bla2 );
}
Then I run this command:
PKG_CXXFLAGS=`Rscript -e 'Rcpp:::CxxFlags()'` PKG_LIBS=`Rscript -e
'Rcpp:::LdFlags()'` R CMD SHLIB test.cpp
Afterwards I start R and run these commands in R:
require(Rcpp)
yada - Module(yada)
yada$bar( 2L )
yada$foo( 2L, 10.0 )
yada$hello()
yada$bla()
yada$bla1( 2L)
yada$bla2( 2L, 5.0 )
And it ends up with this error:
Error in Module(module, mustStart = TRUE) :
Failed to initialize module pointer: Error in
FUN(_rcpp_module_boot_yada[[1L]], ...): no such symbol
_rcpp_module_boot_yada in package .GlobalEnv
This happens all the time with modules. Did I overlook something or what am I
doing wrong?
David
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Distribution of Rcpp codebase
Le 7 avr. 2014 à 15:13, Gábor Csárdi csardi.ga...@gmail.com a écrit : On Mon, Apr 7, 2014 at 4:12 AM, Romain François rom...@r-enthusiasts.com wrote: [...] However, in terms of wins: - package developers would know for sure which version of the codebase is used with their package. Once they have done testing, they don’t have to be hostage of api breakage and things like « please recompile your package, etc … » - developers of Rcpp* are less trapped by the compatibility issues, hands are set free to innovate. The only small downsides I see here is that (1) users potentially have to do more work to include Rcpp* in their packages (although you can just write an R function to include/update their Rcpp* versions); and that (2) source packages will be somewhat bigger. The difference is that if they don’t want a new version, they can stick with the version they have in their package. So when they want newer Rcpp, they can have it, but they are not forced to do anything when the Rcpp* team wants to update the codebase. About 1). We just need to find a good way to propagate newer Rcpp* into a repo. Maybe through git subtree, git sub modules or something. We can come up with some tools. About 2). So What ;) Btw. you are essentially simulating versioned package dependencies this way. :) Yep. The next thing to consider is that Rcpp is not just Rcpp, there are really nice extensions like RcppArmadillo, etc ... perhaps we could setup some tools (e.g. RcppJam) to combine several header only libraries into the end package, instead of what we do now, which is have some headers in Rcpp, some in RcppArmadillo, some in RcppGSL, … with every risk of one being outdated or out of sync with the other. Exactly. IMHO this could work well and take the pressure of both Rcpp* developers and users. Gabor ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] No no no -- Distribution of Rcpp codebase
Le 7 avr. 2014 à 15:34, Dirk Eddelbuettel e...@debian.org a écrit : Romain, Gabor, Would you considerr taking this discussion elsewhere? This is a broad discussion that might be relevant to anyone doing R and C++ work. So no. Or at least make it very clear that you are talking about the Rcpp11, which as AFAICT has not left Github. Rcpp11 needs R 3.1.0, so of course it is not on CRAN yet. But this discussion is not about the Rcpp11 package, it is not about the Rcpp package. It is about exchanging ideas about what would be beneficial to the community of people using R and C++. The way the Rcpp codebase is currently distributed might have been the best model for years, but I’m not convinced it is the best solution nowadays, so I wanted to discuss, and this list is the best venue, whether you like it or not. As for Rcpp11, I am indeed going to release it as an R package, but I will also definitely consider alternatives such as snapshotting the distribution as part of the client package. I think there are advantages to doing that. But don’t worry, I will definitely not do anything to change the Rcpp package. You are doing a fine job of keeping it alive. Rcpp was created as a CRAN package. It remains a CRAN package. It fits squarely into the dependency mechanism of CRAN. It has proven useful, and stable. As a consequence it is as of today used by almost 200 CRAN packages and almost 20 BioC package. Please do not confuse our users by implying that any of this is about to change. You are more than welcome to experiment with new approaches, new implementation, new distributions, ... but *please* make sure you continue to do so under a new name too. or what ? This list is about Rcpp. The CRAN package. In mt view, this list is about R and C++, broadly. At least it was the intention when I created it many years ago. There are plenty of threads in this list that are not stricly related to Rcpp. The world of R and C++ is bigger than Rcpp. Romain ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Distribution of Rcpp codebase
Le 7 avr. 2014 à 19:20, Gábor Csárdi csardi.ga...@gmail.com a écrit : On Mon, Apr 7, 2014 at 9:20 AM, Romain François rom...@r-enthusiasts.com wrote: [...] The only small downsides I see here is that (1) users potentially have to do more work to include Rcpp* in their packages (although you can just write an R function to include/update their Rcpp* versions); and that (2) source packages will be somewhat bigger. The difference is that if they don’t want a new version, they can stick with the version they have in their package. So when they want newer Rcpp, they can have it, but they are not forced to do anything when the Rcpp* team wants to update the codebase. About 1). We just need to find a good way to propagate newer Rcpp* into a repo. Maybe through git subtree, git sub modules or something. We can come up with some tools. Oh, I see, you mean installing Rcpp* dependent packages from git(hub) directly. I imagine some people would want to put the headers into their tree, as ordinary files. Having the files into the client package is what I meant. This way, the developer of the package is in control of what version is used. The challenge is how to make it easy. Others might want to have it as submodules. For the latter to work, I imagine you would need to set up some special repo structure. I think git subtree gives something close to what I mean. But obviously someone could just copy the files manually, it would just be a matter of copying the inst/include directory. Btw. I obviously don't have to tell you, but I want to point it out that this snapshotting is already possible today. I can just take the Rcpp* headers and put them in my package, and then I don't have to worry about future changes. This is assuming the package is header-only. With compiled code it is trickier, because of the name clashes. Good luck doing that with current Rcpp. Many functions are compiled into the shared library shipped with the package. It is not linking as it used to do it, which is the big win of 0.11.0, but there is still a library. Many of these functions go through the namespace of the Rcpp package, etc … so you could snapshot Rcpp, but it would definitely not be easy at all. So I think, the question is whether to support this with some infrastructure, e.g. to update the embedded headers, have them as a git submodule, etc. About 2). So What ;) Agreed. CRAN-core might be fussy about it, though, if source packages get much bigger because of this. Or might be not. This is a drop of water in the ocean of CRAN packages. I think the benefit would outweigh this quite easily. In any case, not gonna happen, at least not with Rcpp. Romain ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Distribution of Rcpp codebase
Thanks to have interest in this discussion. Le 7 avr. 2014 à 20:30, Kevin Ushey kevinus...@gmail.com a écrit : Here's some thoughts, from the perspective of a package developer who might want to use Rcpp11. One option is to have the Rcpp11 distribution live as a git repository within the `inst/include` directory of a developer's package. A package developer could clone the repository (or have it track the inst/include subdirectory of Rcpp11 -- not sure if that's possible), and at their leisure pull the current version, pull a certain tag / release, and so on.). Maybe there's something that needs to be in .Rbuildignore to ensure the .git repository doesn't get added into the built package on R CMD build. Some R functions, e.g. useRcpp11(), could be written that, when run in the package directory, clones a repository in inst/include/Rcpp, and also updates pertinent licensing information (this package uses Rcpp11, which is licensing under so-and-so...). Essentially they would be nice wrappers to git. Maybe package these as part of an Rcpp11 CRAN / GitHub release. I think git subtree is the right tool. I'm not sure how well a mechanism like this would work for syncing across the other Rcpp libraries, e.g. RcppArmadillo, though. As long as these other are header only, that would be pretty easy. We’d have to diverge them as well as they carry various fastLm, etc ... which really don’t belong there (before the Rcpp police gets involves : I know they will stay). One should expect that packages depending on Rcpp11 will still want to be submitted to CRAN, and one potential problem (I know we could say 'not our problem', but we should be good citizens) is that, if R-Core decides to make an R API change that causes these packages to fail R CMD check, it will be more painful for them to accept maintenance releases from all these packages. There are guarantees on R api changes. I don’t see this as an issue. Finally -- we might consider moving this discussion to a new mailing list, since I think Rcpp and Rcpp11 are divergent enough that we should consider Rcpp-devel for Rcpp-the-package-specific discussion, and a different mailing list for Rcpp11 development. Thoughts, Romain? I though this mailing list was about discussing R and C++, but apparently I was wrong. Fair enough if this is just Rcpp related. Perhaps I’ll leave the mailing list as I’m not that interested in Rcpp anymore. Rcpp11 has its own github issues, this I think is enough for now, but sure maybe a new mailing list would be good. On Mon, Apr 7, 2014 at 10:20 AM, Gábor Csárdi csardi.ga...@gmail.com wrote: On Mon, Apr 7, 2014 at 9:20 AM, Romain François rom...@r-enthusiasts.com wrote: [...] The only small downsides I see here is that (1) users potentially have to do more work to include Rcpp* in their packages (although you can just write an R function to include/update their Rcpp* versions); and that (2) source packages will be somewhat bigger. The difference is that if they don't want a new version, they can stick with the version they have in their package. So when they want newer Rcpp, they can have it, but they are not forced to do anything when the Rcpp* team wants to update the codebase. About 1). We just need to find a good way to propagate newer Rcpp* into a repo. Maybe through git subtree, git sub modules or something. We can come up with some tools. Oh, I see, you mean installing Rcpp* dependent packages from git(hub) directly. I imagine some people would want to put the headers into their tree, as ordinary files. Others might want to have it as submodules. For the latter to work, I imagine you would need to set up some special repo structure. Btw. I obviously don't have to tell you, but I want to point it out that this snapshotting is already possible today. I can just take the Rcpp* headers and put them in my package, and then I don't have to worry about future changes. This is assuming the package is header-only. With compiled code it is trickier, because of the name clashes. So I think, the question is whether to support this with some infrastructure, e.g. to update the embedded headers, have them as a git submodule, etc. About 2). So What ;) Agreed. CRAN-core might be fussy about it, though, if source packages get much bigger because of this. Or might be not. Gabor [...] ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Missing libRcpp.a and libRcpp.so
As of Rcpp 0.11.0, those no longer exist. You need to rebuild your packages from source against this Rcpp. See http://r.789695.n4.nabble.com/R-pkgs-Rcpp-0-11-0-td4684675.html Romain Le 25 mars 2014 à 10:24, Florian Burkart florian.burk...@gmail.com a écrit : Hi, This is probably quite straight forward but can't find the answer. I just installed Rcpp through R on a new Ubuntu install - however, /usr/local/lib/R/site-library/Rcpp is missing the lib directory which I have on my old machine. It contains libRcpp.a and libRcpp.so, which I link against (and now can't). How do I build those? Thanks, Florian ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Yet another instance of function 'dataptr' not provided ...
You need to import something, anything from Rcpp’s namespace. Sent you a pull request. Le 25 mars 2014 à 20:17, Douglas Bates ba...@stat.wisc.edu a écrit : I must have been away from writing R/Rcpp code for too long. I started off trying to reproduce a calculation that is, literally, a one-liner in Julia. See http://nbviewer.ipython.org/gist/dmbates/9746197 Now admittedly the calculation of the sums of the n choose k possible subsets of size k from a vector or length n is aided by the fact that there is a combinations iterator in Julia. Nonetheless it is pretty amazing that this can be written as combsums(v::Vector, k) = [sum(c) for c in combinations(v,k)] using this iterator and a comprehension. I tried to write the combinations iterator in C++ but eventually tied myself in knots so I decided to back off and write a function that does the equivalent of the R function sample() and use that to generate a random sample from the distribution of sums. I have the C++ code working using Rcpp attributes but now I must generate a package. I have to be missing something obvious because my attempt at http://github.com/dmbates/randomizationTest produces the dread function 'dataptr' not provided ... message when I try to invoke the R function randomsums. Which of the many vignettes or manuals should I start reading? (I can't believe I have spent two days going through innumerable contortions to try to achieve the effect of a one-liner.) ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Making objects in the C++ side persistent
Creating a package does not give you persistence of external pointers across sessions. Le 20 mars 2014 à 19:52, Dirk Eddelbuettel e...@debian.org a écrit : On 20 March 2014 at 12:40, Jiqiang Guo wrote: | RStan doesn't do anything to persist any c++ object. What's done is to save | the binary file created using package inline in an R object so it can be reused | without recompiling c++ code. So what is in cxxfunplus might not be related. Thanks for the clarification. My recommendation is usually to just create a package. We know that works. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp module support
Rcpp11 is an alternative implementation of Rcpp indeed. It does not mean discussing it is not suitable to this mailing list. Rcpp11 will be released closely after R 3.1.0, whenever this happens to be. It contains major improvements over Rcpp, will be completely header only (no src/ directory at all) and will depend and leverage C++11 greatly. Le 27 févr. 2014 à 03:33, Dirk Eddelbuettel e...@debian.org a écrit : On 26 February 2014 at 21:25, KNAG, RALPH H (RALPH H) wrote: | I just saw a tweet that said that support for Rcpp modules will be dropped in | ?Release 11?. | When will this occur? This mailing list is about Rcpp -- whereas the tweet you refer to (if it was the same one I saw) was about Rcpp11, which is a different project. Dirk ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Avoiding having to write .h files
Hi,
Then just put fun1 and fun2 in the same file. This is yet again less work than
having two files.
Romain
Le 25 févr. 2014 à 12:45, Søren Højsgaard sor...@math.aau.dk a écrit :
Only because it is extra work... Anyway, I hope this
Rcpp::interfaces(r,cpp)-feature gets up and running again :)
Søren
-Original Message-
From: Romain François [mailto:rom...@r-enthusiasts.com]
Sent: 25. februar 2014 12:39
To: Søren Højsgaard
Cc: rcpp-devel@lists.r-forge.r-project.org (rcpp-de...@r-forge.wu-wien.ac.at)
Subject: Re: [Rcpp-devel] Avoiding having to write .h files
Hello,
Why do you want to avoid writing headers. I guess you could use extern
For example, in foo1.cpp :
double fun1(){
return 2.0 ;
}
In foo2.cpp ;
extern double fun1() ;
double fun2(){
return fun1() + 2;
}
Romain
Le 25 févr. 2014 à 12:28, Søren Højsgaard sor...@math.aau.dk a écrit :
Dear all,
If in a package I have foo1.cpp with function fun1 and foo2.cpp with fun2
(which uses fun1 from foo1.cpp) then I must write foo1.h and include in
foo2.cpp. Right? Is there another approach so that I do not have to write
these header files?
Using Rcpp::interfaces(r,cpp) should take care of that (according to the
Rcpp-attributes vignette, at least that is my understanding) but I have seen
on the list that there is a bug in this feature with the current Rcpp
version (and also with the devel version on github).
Cheers
Søren
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Deriving type information
In addition to what Kevin said, perhaps you are looking for macros from this
file:
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/macros/dispatch.h
Le 14 févr. 2014 à 00:34, Søren Højsgaard sor...@math.aau.dk a écrit :
Dear all,
Function foo_num below takes a numeric vector and returns a list with the
first element of the vector. (Not very interesting function). I want to
create a templated version of this in function do_foo below, but whether a
should be a double, an integer, or a string depends on the RTYPE.
My question is (and it is embarrasing to ask because I believe Romain has
already answered it; just can't find the answer) how to derive the what type
a should have once we know RTYPE??
My second question is: Isn't there an easier general way to write the
dispatch function (I have in mind situations where the templated function
takes *more* than one argument!)? I have in mind something like:
int type = TYPEOF(XX_) ;
return do_footype ( XX_ ) ;
but that fails because INTSXP, REALSXP etc seems to be defined as const's
(thats my reading of the compiler message).
What goes into template parameters is compile time constant. And the type of an
R object is dynamic, there is no way to know before runtime, so the compiler
can not do this for you.
Thanks
Søren
#include Rcpp.h
using namespace Rcpp;
//[[Rcpp::export]]
List foo_num(NumericVector x){
double a=x[0];
return List::create( a );
}
template int RTYPE
List do_foo( VectorRTYPE x ){
double a=x[0]; // WHAT TO DO HERE???
return List::create( a );
}
SEXP foo_any( SEXP XX_){
int type = TYPEOF(XX_) ;
switch( type ){
case INTSXP : return do_fooINTSXP ( XX_ ) ;
case REALSXP : return do_fooREALSXP( XX_ ) ;
case STRSXP : return do_fooSTRSXP ( XX_ ) ;
}
return R_NilValue ;
}
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Wierd compilation error
The attributes parser does not know how to handle the static keyword. Works for
me without it.
You get the line number of the generated file. Use verbose = TRUE to have a
better clue at what is wrong.
Romain
Le 29 janv. 2014 à 12:24, Alessandro Mammana mamm...@molgen.mpg.de a écrit :
Hi all,
I was experimenting with templates and Rcpp and trying to compile this code:
// [[Rcpp::export]]
static void readVector(VectorINTSXP v){
traits::storage_typeINTSXP::type i = v[0];
Rcout i std::endl;
}
I got this error:
scratchpad.cpp: In function 'SEXPREC* sourceCpp_3062_readVector(SEXP)':
scratchpad.cpp:337:21: error: variable or field '__result' declared void
scratchpad.cpp:338:9: error: '__result' was not declared in this scope
make: *** [scratchpad.o] Error 1
Also, the line numbers don't make any sense, because the file
scratchpad.cpp is only 250 lines long...
Do you know what could be wrong?
Thanks in advance!
Ale
--
Alessandro Mammana, PhD Student
Max Planck Institute for Molecular Genetics
Ihnestraße 63-73
D-14195 Berlin, Germany
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp version of c( )
Hi,
There is currently nothing like that. It is quite hard to generalize.
You might like std::merge, e.g.
template typename Vec
Vec do_conc_(Vec x, Vec y){
Vec out=no_init(x.size()+y.size());
std::merge( x.begin(), x.end(), y.begin(), y.end(), out.begin() ) ;
return out;
}
We could want to generalize this to arbitrary sugar expressions, so that we
could do e.g.
conc( x+x, y+y ) ;
without having to materialize x+x and y+y into their own memory ...
Perhaps it would look like this:
template int RTYPE, typename T1, typename T2
VectorRTYPE concat( const T1 t1, const T2 t2 ){
// use static_assert to make sure T1 and T2 are sugar expressions
int n = t1.size() + t2.size() ;
VectorRTYPE out = no_init(n) ;
std::merge( t1.begin(), t1.end(), t2.begin(), t2.end(), out.begin() ) ;
return out ;
}
Then as Kevin hints (and has opened an issue in
https://github.com/romainfrancois/Rcpp11/issues/92) we can want to go further
and want something with multiple inputs.
Interesting idea, I guess lots of work to generalize it.
Romain
Le 21 janv. 2014 à 23:02, Søren Højsgaard sor...@math.aau.dk a écrit :
Dear all,
I have made the following primitive concatenate function, because I
couldn't find one in Rcpp:
template const int RTYPE
VectorRTYPE do_conc_(VectorRTYPE x, VectorRTYPE y){
int nx=x.size(), n=x.size()+y.size(),i,j;
VectorRTYPE out=no_init(n);
for (i=0; inx; ++i){ out[ i ] = x[ i ];}
for (j=i, i=0; jn; ++j, ++i){ out[ j ] = y[i] ;}
return out;
}
// [[Rcpp::export]]
SEXP conc( SEXP XX_, SEXP YY_){
int type = TYPEOF(XX_) ;
switch( type ){
case INTSXP : return do_conc_INTSXP ( XX_, YY_ ) ;
case REALSXP : return do_conc_REALSXP( XX_, YY_ ) ;
case STRSXP : return do_conc_STRSXP ( XX_, YY_ ) ;
case VECSXP : return do_conc_VECSXP ( XX_, YY_ ) ;
}
return R_NilValue ;
}
As you can see it assumes that the two inputs XX_ and YY_ are of the same
type, and it fails to copy names to the output. If I have missed any such
functionality in Rcpp then I would be happy to know...
Cheers
Søren
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp version of c( )
Le 22 janv. 2014 à 01:10, Kevin Ushey kevinus...@gmail.com a écrit :
Hi Søren,
I like the idea. Currently there is nothing like that in Rcpp. It
could be made more flexible if we:
1. Accept a generic set of vectors that could be appropriately casted as
needed,
2. Cast these vectors to the appropriate type if necessary,
3. Fill an output vector with the elements of these vectors.
Of course, we would like to be able to accept primitives as well so
that e.g. c(x, 1, y) works so something a bit more designed would be
nice.
there is also the problem of names, e.g. c(x, foo = 1, y). This is a big part
of the problem with ::create
As a first approximation, perhaps we could ignore names.
There should be a flexible way to implement this using variadic
templates, so that e.g.
template typename T, typename... Args
T c( Args... args ) {
...do the concatenation…
}
I’ll discuss more on the issue you opened or if you create a branch for the
feature in Rcpp11. I guess the R type must play a role, so I’d imagine an
interface more like this :
template int RTYPE, typename... Args
VectorRTYPE c( Args... args ) {
static_assert( all types in Args are compatible with RTYPE )
- find the final length
- allocate a vector of that length
- recursively iterate through args
}
Once you understand them, variadic templates are quite fun to work with. On a
related note, I’ve added a structure function recently to Rcpp11.
Of course, this requires C++11 so it might not fit until R 3.1.0 is
out with its C++11 support, but it could be a natural fit in Rcpp11.
Adding the generic version in Rcpp would require code bloat
unfortunately.
This might be fun to produce with C++11, but a massive pain with C++98.
Romain
-Kevin
On Tue, Jan 21, 2014 at 2:02 PM, Søren Højsgaard sor...@math.aau.dk wrote:
Dear all,
I have made the following primitive concatenate function, because I
couldn't find one in Rcpp:
template const int RTYPE
VectorRTYPE do_conc_(VectorRTYPE x, VectorRTYPE y){
int nx=x.size(), n=x.size()+y.size(),i,j;
VectorRTYPE out=no_init(n);
for (i=0; inx; ++i){ out[ i ] = x[ i ];}
for (j=i, i=0; jn; ++j, ++i){ out[ j ] = y[i] ;}
return out;
}
// [[Rcpp::export]]
SEXP conc( SEXP XX_, SEXP YY_){
int type = TYPEOF(XX_) ;
switch( type ){
case INTSXP : return do_conc_INTSXP ( XX_, YY_ ) ;
case REALSXP : return do_conc_REALSXP( XX_, YY_ ) ;
case STRSXP : return do_conc_STRSXP ( XX_, YY_ ) ;
case VECSXP : return do_conc_VECSXP ( XX_, YY_ ) ;
}
return R_NilValue ;
}
As you can see it assumes that the two inputs XX_ and YY_ are of the same
type, and it fails to copy names to the output. If I have missed any such
functionality in Rcpp then I would be happy to know...
Cheers
Søren
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp version of c( )
Hi,
There is a preliminary version of this in Rcpp11. For example:
#include Rcpp.h
using namespace Rcpp ;
// [[Rcpp::export]]
NumericVector test(){
NumericVector x(10) ;
NumericVector y(30) ;
return NumericVector::concat(x, 2.0, y, 1.0) ;
}
So it handles (or at least it should):
- compatible primitive (i.e. double in the case of NumericVector)
- arbitrary compatible sugar expression
It is at least for now a static member function of the Vector class. Maybe it
can be made a free function.
This is about 90 lines of C++11 code.
Romain
Le 22 janv. 2014 à 01:37, Søren Højsgaard sor...@math.aau.dk a écrit :
Hi Kevin,
Thanks for your reply. I was only introduced to C++11 last week (my fault!);
it seems that everybodys life becomes much easier once R-packages can be made
with that...
I think many Rcpp-friends would welcome a version of c( ). One view is of
course that it should be as general as R's c( )-function. A more pragmatic
view is a version of c() that could concatenate (a) two lists and (b) two
vectors (where each can be integers, doubles, characters and complex,
independently of each other). I guess that would satisfy 90+% of the needs
for a c( ) function in an Rcpp setting...
Best regards
Søren
-Original Message-
From: Kevin Ushey [mailto:kevinus...@gmail.com]
Sent: 22. januar 2014 01:10
To: Søren Højsgaard
Cc: rcpp-devel@lists.r-forge.r-project.org (rcpp-de...@r-forge.wu-wien.ac.at)
Subject: Re: [Rcpp-devel] Rcpp version of c( )
Hi Søren,
I like the idea. Currently there is nothing like that in Rcpp. It could be
made more flexible if we:
1. Accept a generic set of vectors that could be appropriately casted as
needed, 2. Cast these vectors to the appropriate type if necessary, 3. Fill
an output vector with the elements of these vectors.
Of course, we would like to be able to accept primitives as well so that e.g.
c(x, 1, y) works so something a bit more designed would be nice.
There should be a flexible way to implement this using variadic templates, so
that e.g.
template typename T, typename... Args
T c( Args... args ) {
...do the concatenation...
}
Of course, this requires C++11 so it might not fit until R 3.1.0 is out with
its C++11 support, but it could be a natural fit in Rcpp11.
Adding the generic version in Rcpp would require code bloat unfortunately.
-Kevin
On Tue, Jan 21, 2014 at 2:02 PM, Søren Højsgaard sor...@math.aau.dk wrote:
Dear all,
I have made the following primitive concatenate function, because I
couldn't find one in Rcpp:
template const int RTYPE
VectorRTYPE do_conc_(VectorRTYPE x, VectorRTYPE y){
int nx=x.size(), n=x.size()+y.size(),i,j;
VectorRTYPE out=no_init(n);
for (i=0; inx; ++i){ out[ i ] = x[ i ];}
for (j=i, i=0; jn; ++j, ++i){ out[ j ] = y[i] ;}
return out;
}
// [[Rcpp::export]]
SEXP conc( SEXP XX_, SEXP YY_){
int type = TYPEOF(XX_) ;
switch( type ){
case INTSXP : return do_conc_INTSXP ( XX_, YY_ ) ;
case REALSXP : return do_conc_REALSXP( XX_, YY_ ) ;
case STRSXP : return do_conc_STRSXP ( XX_, YY_ ) ;
case VECSXP : return do_conc_VECSXP ( XX_, YY_ ) ;
}
return R_NilValue ;
}
As you can see it assumes that the two inputs XX_ and YY_ are of the same
type, and it fails to copy names to the output. If I have missed any such
functionality in Rcpp then I would be happy to know...
Cheers
Søren
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-deve
l
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] how to create an Rcpp::List in a standalone C++ application?
Hi,
You need to embed R and load Rcpp, otherwise this won’t work.
You can do this either from scratch. See
http://cran.r-project.org/doc/manuals/R-exts.html#Embedding-R-under-Unix_002dalikes
Or you can use RInside.
Romain
Le 18 déc. 2013 à 12:12, Florian Oswald florian.osw...@gmail.com a écrit :
Hi All,
I have a C++ class that I build and test without the help of Rcpp.
I use Rcpp as an interface, inputting and outputting data from and to the
class. I'm stuck at the outputter. Ideally I would like to have this at the
end of my program:
Rcpp::List Results = MyClass.ExportToR();
where ExportToR is a method that creates an Rcpp::List from members of
MyClass. However, I'm unable to use components of Rcpp.h in my code; In
particular, I'm unable to make this toy example work:
#include iostream
#include cstdlib
#include blitz/array.h
#include Rcpp.h
#include R.h
using namespace std;
int main(int argc, char *argv[])
{
Rcpp::IntegerVector d;
// Rcpp::List L; want to use
// L to output results to R.
return EXIT_SUCCESS;
}
I compile it with
llvm-g++-4.2 -arch x86_64 -I/Library/Frameworks/R.framework/Resources/include
-DNDEBUG -W -I/usr/local/include -I/usr/local/include
-I/Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/include
-L/Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/lib/
-L/Library/Frameworks/R.framework/Versions/3.0/Resources/lib export.cpp
-lRcpp -lR -o export
which compiles, but produces a segfault.
Thanks for any help!
Florian
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] How many copies of my object do I make?
Le 9 déc. 2013 à 23:14, Søren Højsgaard sor...@math.aau.dk a écrit :
Dear all,
Using RcppEigen I've created a function for converting a sparse matrix (a
dgCMatrix) to a standard dense matrix:
typedef Eigen::SparseMatrixdouble SpMatd;
typedef Eigen::MappedSparseMatrixdouble MSpMat;
// [[Rcpp::export]]
SEXP do_dgCMatrix2matrix ( SEXP XX_ ){
S4 DD(wrap(XX_));
List dn = clone(List(DD.slot(Dimnames)));
SpMatd X(asSpMatd(XX_));
Eigen::MatrixXd dMat;
dMat = Eigen::MatrixXd( X );
NumericMatrix Xout(wrap(dMat));
Xout.attr(dimnames) = dn;
return Xout;
}
The function does what I expect it to, but I am curious about how many times
I really create some sort of copy of my input matrix and when all I do is
put a small layer of vernish over my input matrix?
1) dMat is dense matrix, and that must (I guess) refer to new object??
2) X is a sparse matrix, and I suppose it is a new object??
Data copy is done in the as implementation for SpMatd, see here for what really
happens:
https://github.com/RcppCore/RcppEigen/blob/master/inst/include/RcppEigenWrap.h#L301
So you pay for copying data from the R representation to the Eigen
representation, which are not the same.
You don’t pay for a copy from what as returns to X because of RVO. Most
compilers will optimize this for you.
2') If I had declared it to be MSpMat, then it would really just be the input
object with a few bells and whistles??
Yes. As far as I understand that code:
https://github.com/RcppCore/RcppEigen/blob/master/inst/include/RcppEigenWrap.h#L284
3) But how about DD and Xout? Are they new objects (in terms of memory usage)?
To start with, you don’t need wrap(XX_), as XX_ is a SEXP, and you could have
S4 in the signature of the function, which would make the intent clearer. By
the same token you can have your function return a NumericMatrix.
S4 DD ; just makes sure the data you pass to it is an S4 object. It does not do
deep copy of your data.
wrap(dMat) causes copy of the eigen representation into an R representation.
This makes data copy. wrap returns a SEXP.
When this SEXP gets into Xout, no copy is done.
Romain
Put differently, if my input matrix occupies B bytes of memory, how many
times B have I then created along the way?
All the best
Søren
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] IntegerVector initialization
Le 12/01/12 11:29, Gregor Kastner a écrit : This is a minor thing but caused some confusion to me: IntegerVector foo1(2, 4.0); // works IntegerVector foo2(2, 4);// throws error while IntegerVector bar1 = IntegerVector::create(4.0, 4.0); // works IntegerVector bar2 = IntegerVector::create(4, 4); // works Bug or feature? Best, /g This should be fixed in rev 3440. This was due to some compiler ambiguities, so I just added some disambiguation. Romain -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Idiom for accessing scalars
Le 06/01/12 20:46, Douglas Bates a écrit :
On Fri, Jan 6, 2012 at 1:12 PM, Dirk Eddelbuettele...@debian.org wrote:
On 6 January 2012 at 12:59, Douglas Bates wrote:
| On Fri, Jan 6, 2012 at 12:39 PM, John Chambersj...@stat.stanford.edu wrote:
| The Rf_ part of the API in particular is ugly and somewhat of an add-on
| forced in a few examples by the use of some common names in the macro files.
|
| But, as it stands, that is a requirement when using Rcpp.
Where? I can think of one propagated use, which is at the bottom of the
try/catch structure where we use ::Rf_error. But the commonly used macros
hide it, and we could/should obviously wrap this.
Otherwise, and especially since the 'Rcpp sugar' initiative took off, I don't
really touch any ::Rf_* myself anymore. Inside the Rcpp code base, sure. But
not really in user-facing stuff and Rcpp applications.
I didn't make myself clear. What I meant was that it is not possible
to use asInteger in Rcpp and count on the name being remapped to
Rf_asInteger.
| I think of the Rf_ part as more due to the fact that C doesn't have a
| concept of namespaces so anything in the R API is at the top level
| namespace leading to some conflicts.
Agreed. But speaking stylistically, for the same reason that we prefer C++
versions of C header files (eg cstdint over stdint.h, cstdio over stdio.h,
...) I am with John on the preference for C++ idioms when given a choice.
I suppose I could have just checked whether Rcpp::asint calls
Rf_asInteger. If so, everything is cool. Unfortunately, I haven't
been able to find that specialization.
as lives in the inst/include/Rcpp/as.h file, and we have to follow
template wizardry:
it starts from :
template typename T T as( SEXP m_sexp) {
return internal::asT( m_sexp, typename
traits::r_type_traitsT::r_category() ) ;
}
with T=int, so we end up calling this one:
template typename T T as( SEXP x, ::Rcpp::traits::r_type_primitive_tag ) {
if( ::Rf_length(x) != 1 ) throw ::Rcpp::not_compatible(
expecting a single value ) ;
const int RTYPE = ::Rcpp::traits::r_sexptype_traitsT::rtype ;
SEXP y = PROTECT( r_castRTYPE(x) );
typedef typename ::Rcpp::traits::storage_typeRTYPE::type
STORAGE;
T res = casterSTORAGE,T( *r_vector_startRTYPE,STORAGE(
y ) ) ;
UNPROTECT(1) ;
return res ;
}
which does the magic. There is no calls to asInteger.
Romain
--
Romain Francois
Professional R Enthusiast
http://romainfrancois.blog.free.fr
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] When does using iterators for subscripting help?
I thought I could make a difference by trying some loop unrolling
voodoo, with this macro:
#define LOOP_UNROLL(EXPR) \
int __trip_count = n 2 ; \
int i = 0 ; \
for ( ; __trip_count 0 ; --__trip_count) { \
EXPR ; i++ ; \
EXPR ; i++ ; \
EXPR ; i++ ; \
EXPR ; i++ ; \
} \
switch (n - i){ \
case 3: \
EXPR ; i++ ; \
case 2: \
EXPR ; i++ ; \
case 1: \
EXPR ; i++ ; \
case 0: \
default:\
{} \
}
and these versions:
count_bin_unroll - cxxfunction(signature(x = numeric, binwidth =
numeric, origin = numeric, nbins = integer), '
int nbins_ = asint(nbins);
double binwidth_ = asdouble(binwidth);
double origin_ = asdouble(origin);
Rcpp::NumericVector counts(nbins_);
Rcpp::NumericVector x_(x);
int n = x_.size();
LOOP_UNROLL(( counts[(int) ((x_[i] - origin_) / binwidth_)]++ ))
return counts;
', plugin = Rcpp, includes = readLines( loopunroll.h ) )
count_bini_unroll - cxxfunction(signature(x = numeric, binwidth =
numeric, origin = numeric, nbins = integer), '
int nbins_ = asint(nbins);
double binwidth_ = asdouble(binwidth);
double origin_ = asdouble(origin);
Rcpp::NumericVector counts(nbins_);
Rcpp::NumericVector x_(x);
int n = x_.size();
Rcpp::NumericVector::iterator x_i = x_.begin();
Rcpp::NumericVector::iterator counts_i = counts.begin();
LOOP_UNROLL(( counts_i[(int) ( (x_i[i] - origin_) / binwidth_)]++ ))
return counts;
', plugin = Rcpp, includes = readLines( loopunroll.h ) )
But it turns out it does not help much. I get these:
Unit: milliseconds
expr min lq median uq max
1iterator 31.26655 31.52351 31.64775 31.81314 89.9450
2 iterator_unroll 32.12131 32.34650 32.48870 32.69931 109.7043
3operator 33.35224 33.59498 33.73557 33.91297 126.1293
4 operator_unroll 33.62351 33.77934 33.93898 34.28303 118.9024
But I wanted to share it anyway.
Romain
Le 04/01/12 15:16, Hadley Wickham a écrit :
Hi all,
Slightly less dense question (hopefully). In the code below I have
two versions of the same function - one uses operator[] and the other
uses iterators. Following the Rcpp introduction, I had expected the
iterator version to be substantially faster, but I'm only seeing a
minor improvement (~10%). Why doesn't using iterators help me much
here? Possible explanations:
* I'm using iterators incorrectly in my code
* Iterators help most when the vector access is sequential, and here
the counts index is bouncing all over the place, so I shouldn't expect
much improvement.
Any ideas would be much appreciated. Thanks!
Hadley
library(inline)
count_bin- cxxfunction(signature(x = numeric, binwidth =
numeric, origin = numeric, nbins = integer), '
int nbins_ = asint(nbins);
double binwidth_ = asdouble(binwidth);
double origin_ = asdouble(origin);
Rcpp::NumericVector counts(nbins_);
Rcpp::NumericVector x_(x);
int n = x_.size();
for(int i = 0; i n; i++) {
counts[(int) ((x_[i] - origin_) / binwidth_)]++;
}
return counts;
', plugin = Rcpp)
count_bini- cxxfunction(signature(x = numeric, binwidth =
numeric, origin = numeric, nbins = integer), '
int nbins_ = asint(nbins);
double binwidth_ = asdouble(binwidth);
double origin_ = asdouble(origin);
Rcpp::NumericVector counts(nbins_);
Rcpp::NumericVector x_(x);
int n = x_.size();
Rcpp::NumericVector::iterator x_i = x_.begin();
Rcpp::NumericVector::iterator counts_i = counts.begin();
for(int i = 0; i n; i++) {
counts_i[(int) ((x_i[i] - origin_) / binwidth_)]++;
}
return counts;
', plugin = Rcpp)
x- rnorm(1e7, sd = 3)
origin- min(x)
binwidth- 1
n- ceiling((max(x) - origin) / binwidth)
system.time(y1- count_bin(x, binwidth, origin, nbins = n))
system.time(y2- count_bini(x, binwidth, origin, nbins = n))
all.equal(y1, y2)
library(microbenchmark)
microbenchmark(
operator = count_bin(x, binwidth, origin, nbins = n),
iterator = count_bini(x, binwidth, origin, nbins = n))
)
# The real reason I'm exploring this is as a more efficient version
# of tabulate for doing equal bin counts. The Rcpp version is about 10x
# faster, mainly (I think) because it avoids creating a modified copy of the
# vector
system.time(y3- tabulate((x - origin) / binwidth + 1, nbins = n))
all.equal(y1, y3)
--
Romain Francois
Professional R Enthusiast
http://romainfrancois.blog.free.fr
___
Rcpp-devel mailing list
Re: [Rcpp-devel] Idiom for accessing scalars
Le 07/01/12 17:04, Douglas Bates a écrit :
2012/1/7 Romain Françoisrom...@r-enthusiasts.com:
Le 06/01/12 20:46, Douglas Bates a écrit :
On Fri, Jan 6, 2012 at 1:12 PM, Dirk Eddelbuettele...@debian.orgwrote:
On 6 January 2012 at 12:59, Douglas Bates wrote:
| On Fri, Jan 6, 2012 at 12:39 PM, John Chambersj...@stat.stanford.edu
wrote:
|The Rf_ part of the API in particular is ugly and somewhat of an
add-on
|forced in a few examples by the use of some common names in the macro
files.
|
| But, as it stands, that is a requirement when using Rcpp.
Where? I can think of one propagated use, which is at the bottom of the
try/catch structure where we use ::Rf_error. But the commonly used
macros
hide it, and we could/should obviously wrap this.
Otherwise, and especially since the 'Rcpp sugar' initiative took off, I
don't
really touch any ::Rf_* myself anymore. Inside the Rcpp code base, sure.
But
not really in user-facing stuff and Rcpp applications.
I didn't make myself clear. What I meant was that it is not possible
to use asInteger in Rcpp and count on the name being remapped to
Rf_asInteger.
| I think of the Rf_ part as more due to the fact that C doesn't have a
| concept of namespaces so anything in the R API is at the top level
| namespace leading to some conflicts.
Agreed. But speaking stylistically, for the same reason that we prefer
C++
versions of C header files (eg cstdint over stdint.h, cstdio over
stdio.h,
...) I am with John on the preference for C++ idioms when given a choice.
I suppose I could have just checked whether Rcpp::asintcalls
Rf_asInteger. If so, everything is cool. Unfortunately, I haven't
been able to find that specialization.
as lives in the inst/include/Rcpp/as.h file, and we have to follow template
wizardry:
it starts from :
templatetypename T T as( SEXP m_sexp) {
return internal::asT( m_sexp, typename
traits::r_type_traitsT::r_category() ) ;
}
with T=int, so we end up calling this one:
templatetypename T T as( SEXP x, ::Rcpp::traits::r_type_primitive_tag ) {
if( ::Rf_length(x) != 1 ) throw ::Rcpp::not_compatible(
expecting a single value ) ;
const int RTYPE = ::Rcpp::traits::r_sexptype_traitsT::rtype ;
SEXP y = PROTECT( r_castRTYPE(x) );
typedef typename ::Rcpp::traits::storage_typeRTYPE::type
STORAGE;
T res = casterSTORAGE,T( *r_vector_startRTYPE,STORAGE( y ) )
;
UNPROTECT(1) ;
return res ;
}
which does the magic. There is no calls to asInteger.
Which, to me, is the disadvantage. The asInteger function is brief,
understandable, flexible and well-tested. This may look transparent
to you but not to many others.
We could add another level of indirection and call asInteger, etc ... I
don't mind either way.
Romain
--
Romain Francois
Professional R Enthusiast
http://romainfrancois.blog.free.fr
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Idiom for accessing scalars
Le 04/01/12 14:29, Hadley Wickham a écrit : Hi all, I'm still just getting my feet wet in Rcpp, so please excuse the naivety of my question, but is this the appropriate idiom for treating an input as a C++ scalar? f- cxxfunction(signature(x = integer), plugin = Rcpp, ' Rcpp::IntegerVector x1(x); int x2 = x1[0]; return(Rcpp::NumericVector(x2)); ') i.e. is there any way I can turn x in x2 more succinctly? (This function is just for illustrative purposes - I'm trying to do something at least a little more complicated) Thanks! Hadley Yep, We have as for this, and wrap for the other way around: f- cxxfunction(signature(x = integer), plugin = Rcpp, ' int x2 = asint(x) ; return wrap(x2) ; ') Romain -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] When does using iterators for subscripting help?
Hi,
NumericVector:::iterator is actually alias to double*. Here is a trick
(probably does not work on not gcc compilers):
cxxfunction( , 'Rprintf( %s, DEMANGLE(NumericVector::iterator)); ',
plugin = Rcpp )()
double*NULL
We did good on the NumericVector::operator[] to optimize it as much as
possible, in theory, with proper inlining we should not even see the
difference.
I don't see a wrong use of iterators or a way to make it fly faster still.
Romain
Le 04/01/12 15:16, Hadley Wickham a écrit :
Hi all,
Slightly less dense question (hopefully). In the code below I have
two versions of the same function - one uses operator[] and the other
uses iterators. Following the Rcpp introduction, I had expected the
iterator version to be substantially faster, but I'm only seeing a
minor improvement (~10%). Why doesn't using iterators help me much
here? Possible explanations:
* I'm using iterators incorrectly in my code
* Iterators help most when the vector access is sequential, and here
the counts index is bouncing all over the place, so I shouldn't expect
much improvement.
Any ideas would be much appreciated. Thanks!
Hadley
library(inline)
count_bin- cxxfunction(signature(x = numeric, binwidth =
numeric, origin = numeric, nbins = integer), '
int nbins_ = asint(nbins);
double binwidth_ = asdouble(binwidth);
double origin_ = asdouble(origin);
Rcpp::NumericVector counts(nbins_);
Rcpp::NumericVector x_(x);
int n = x_.size();
for(int i = 0; i n; i++) {
counts[(int) ((x_[i] - origin_) / binwidth_)]++;
}
return counts;
', plugin = Rcpp)
count_bini- cxxfunction(signature(x = numeric, binwidth =
numeric, origin = numeric, nbins = integer), '
int nbins_ = asint(nbins);
double binwidth_ = asdouble(binwidth);
double origin_ = asdouble(origin);
Rcpp::NumericVector counts(nbins_);
Rcpp::NumericVector x_(x);
int n = x_.size();
Rcpp::NumericVector::iterator x_i = x_.begin();
Rcpp::NumericVector::iterator counts_i = counts.begin();
for(int i = 0; i n; i++) {
counts_i[(int) ((x_i[i] - origin_) / binwidth_)]++;
}
return counts;
', plugin = Rcpp)
x- rnorm(1e7, sd = 3)
origin- min(x)
binwidth- 1
n- ceiling((max(x) - origin) / binwidth)
system.time(y1- count_bin(x, binwidth, origin, nbins = n))
system.time(y2- count_bini(x, binwidth, origin, nbins = n))
all.equal(y1, y2)
library(microbenchmark)
microbenchmark(
operator = count_bin(x, binwidth, origin, nbins = n),
iterator = count_bini(x, binwidth, origin, nbins = n))
)
# The real reason I'm exploring this is as a more efficient version
# of tabulate for doing equal bin counts. The Rcpp version is about 10x
# faster, mainly (I think) because it avoids creating a modified copy of the
# vector
system.time(y3- tabulate((x - origin) / binwidth + 1, nbins = n))
all.equal(y1, y3)
--
Romain Francois
Professional R Enthusiast
http://romainfrancois.blog.free.fr
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Segfaults
Le 04/01/12 15:55, Hadley Wickham a écrit :
So your i_[0] - 1 is also nan. You are responsible for dealing with na.
You can use traits::is_na:
fx- cxxfunction( signature( x_ = numeric), '
double x = asdouble(x_) ;
if( traits::is_naREALSXP(x) ){
// do something
} else {
// do something else
}
', plugin = Rcpp )
or perhaps if you don't like the whole traits::is_naREALSXP thing, you
could use e.g. somethin like this:
templatetypename T
bool isna( T x ){
return traits::is_natraits::r_sexptype_traitsT::rtype (x) ;
}
so that you coud just call
if( isna(x) ){ ... }
What are the advantages/disadvantages of doing that over (say) x_[i]
== NA_REAL ?
Hadley
it works ;-)
x == NA_REAL does not work.
Try this:
fx - cxxfunction( signature( x_ = numeric), '
double x = asdouble(x_) ;
if( x == NA_REAL) {
return wrap( true ) ;
} else {
return wrap(false) ;
}
', plugin = Rcpp )
fx( NA )
Romain
--
Romain Francois
Professional R Enthusiast
http://romainfrancois.blog.free.fr
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Segfaults
Le 04/01/12 15:55, Steve Lianoglou a écrit : Woops -- seems I misdiagnosed the cause of error, please ignore :-) Still, I'm surprised the attempted logical (NA) to Numeric conversion isn't a source of some potential woes, too? That is because the NumericVector constructor coerces the logical to a numeric. On Wed, Jan 4, 2012 at 9:50 AM, Steve Lianoglou mailinglist.honey...@gmail.com wrote: Hi, On Wed, Jan 4, 2012 at 9:33 AM, Hadley Wickhamhad...@rice.edu wrote: Hi all, Is it a bug to cause a segfault with Rcpp? Or are am I doing something so dumb that an automatic check could never protect? See minimal reproducible example below. Hadley library(inline) f- cxxfunction(signature(x = numeric, i = numeric), plugin = Rcpp, ' Rcpp::NumericVector x_(x); Rcpp::NumericVector i_(i); x_[(int) (i_[0]) - 1] = 1000; return(x_); ') f(1:10, 1) # works f(1:10, 1.5) # also works f(1:10, NA) # segfaults I reckon that's because `NA` is actually of `logical` type, where your first to examples are of the correct (real/double) type. When I use inline for anything semi-permanent (the last step before turning it into a package, let's say), I typically have a thin R wrapper function that calls down to my inline function and I never call the inline function directly anywhere else. The job of the thin R wrapper function is to sanity check and/or coerce the vars to the correct type before they are past to the inline'd function to avoid the segfault. -steve -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Compilation on MAC OS X 10.7.2
Bonjour Remi, Could you send a reproducible example using tr1::unordered_map so that we can help you. Cordialement, Romain Le 07/12/11 16:55, Rémi Lebret a écrit : Hi, I got this error when I'm trying to compile my package using Rcpp : g++-4.2 -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I/usr/local/include -I/Library/Frameworks/R.framework/Versions/2.14/Resources/library/Rcpp/include -fPIC -g -O2 -c clusteringMain.cpp -o clusteringMain.o In file included from /usr/include/c++/4.2.1/tr1/unordered_map:38, from /Library/Frameworks/R.framework/Versions/2.14/Resources/library/Rcpp/include/RcppCommon.h:130, from /Library/Frameworks/R.framework/Versions/2.14/Resources/library/Rcpp/include/Rcpp.h:27, from clusteringMain.cpp:91: /usr/include/c++/4.2.1/tr1/functional_hash.h: In member function 'size_t std::tr1::hashstd::basic_stringchar, std::char_traitschar, std::allocatorchar ::operator()(const std::string) const': /usr/include/c++/4.2.1/tr1/functional_hash.h:144: error: 'const struct std::basic_stringchar, std::char_traitschar, std::allocatorchar ' has no member named 'Rf_length' /usr/include/c++/4.2.1/tr1/functional_hash.h: In member function 'size_t std::tr1::hashstd::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::operator()(const std::wstring) const': /usr/include/c++/4.2.1/tr1/functional_hash.h:156: error: 'const struct std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ' has no member named 'Rf_length' make: *** [clusteringMain.o] Error 1 It looks like there is a problem with the tr1::unordered_map Any help ? Rémi Rémi Lebret Ingénieur de recherche CNRS Laboratoire de mathématiques de Lille1 - UMR 8524 Batiment M3 - Bureau 322 Tel: 03 20 43 67 82 remi.leb...@math.univ-lille1.fr mailto:remi.leb...@math.univ-lille1.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Compilation on MAC OS X 10.7.2
(please keep ccing the list) neither do we use unordered_map, IIRC. Without a reproducible example, there is very little I can do to help. I have no idea what is in clusteringMain. Romain Le 07/12/11 17:22, Rémi Lebret a écrit : Cher Romain, I don't use any tr1::unordered_map function in my program. The error comes from the inclusion of Rcpp.h (line 91) in my main.cpp And the package compiles fine under Linux. Rémi Le 7 déc. 2011 à 16:59, Romain François a écrit : Bonjour Remi, Could you send a reproducible example using tr1::unordered_map so that we can help you. Cordialement, Romain Le 07/12/11 16:55, Rémi Lebret a écrit : Hi, I got this error when I'm trying to compile my package using Rcpp : g++-4.2 -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I/usr/local/include -I/Library/Frameworks/R.framework/Versions/2.14/Resources/library/Rcpp/include -fPIC -g -O2 -c clusteringMain.cpp -o clusteringMain.o In file included from /usr/include/c++/4.2.1/tr1/unordered_map:38, from /Library/Frameworks/R.framework/Versions/2.14/Resources/library/Rcpp/include/RcppCommon.h:130, from /Library/Frameworks/R.framework/Versions/2.14/Resources/library/Rcpp/include/Rcpp.h:27, from clusteringMain.cpp:91: /usr/include/c++/4.2.1/tr1/functional_hash.h: In member function ‘size_t std::tr1::hashstd::basic_stringchar, std::char_traitschar, std::allocatorchar ::operator()(const std::string) const’: /usr/include/c++/4.2.1/tr1/functional_hash.h:144: error: ‘const struct std::basic_stringchar, std::char_traitschar, std::allocatorchar ’ has no member named ‘Rf_length’ /usr/include/c++/4.2.1/tr1/functional_hash.h: In member function ‘size_t std::tr1::hashstd::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::operator()(const std::wstring) const’: /usr/include/c++/4.2.1/tr1/functional_hash.h:156: error: ‘const struct std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ’ has no member named ‘Rf_length’ make: *** [clusteringMain.o] Error 1 It looks like there is a problem with the tr1::unordered_map Any help ? Rémi Rémi Lebret Ingénieur de recherche CNRS Laboratoire de mathématiques de Lille1 - UMR 8524 Batiment M3 - Bureau 322 Tel: 03 20 43 67 82 remi.leb...@math.univ-lille1.fr mailto:remi.leb...@math.univ-lille1.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org mailto:Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel Rémi Lebret Ingénieur de recherche CNRS Laboratoire de mathématiques de Lille1 - UMR 8524 Batiment M3 - Bureau 322 Tel: 03 20 43 67 82 remi.leb...@math.univ-lille1.fr mailto:remi.leb...@math.univ-lille1.fr -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] multiple function when using Inline
Hello, You are crossing the boundary when it really starts to make sense to make a package. If you only have one R facing C++ function calling other C++ functions, then you can abuse the includes argument of cxxfunction to embed as many C++ functions as you like. Having multiple R facing functions is a little more gymnastic, and rather than explain that, I would prefer you to go down the package route. HTH, Romain Le 20/10/11 08:50, Noah Silverman a écrit : Hi, I've started using Rcpp + inline for some of my code. It is amazingly fast. However, I have need for a few c++ functions. (One main needs to call a few other functions.) At this point, I don't need separate classes, just the ability to have multiple functions. (Coding up several separate R functions using Inline would be ineffecient as the data would need to pass between R and C++ several times on each iteration of a rather large loop. While this is trivial in C++, is it possible in R using the the Rcpp+Inline? -- Noah Silverman UCLA Department of Statistics 8208 Math Sciences Building Los Angeles, CA 90095 ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Romain Francois Professional R Enthusiast http://romainfrancois.blog.free.fr ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Strange behavior of NumericMatrix
Hello,
On a more cosmetic level, you could use the pow function from sugar:
require( Rcpp )
require( inline )
fx- cxxfunction(
signature(),
plugin=Rcpp,
body=
Rcpp::NumericMatrix out_xx(10, 4);
for(int i=0; i4; i++)
out_xx(_,i) = pow( seq(0, 9), i ) ;
return out_xx;
)
fx()
Apart from the use of the sugar version of pow, also note that you do
not need to wrap out_xx, as this implicit (Rcpp::NumericMatrix converts
itself to a SEXP).
Romain
Le 03/09/11 08:51, Steve Lianoglou a écrit :
Hi,
On Sat, Sep 3, 2011 at 12:54 AM, Noah Silvermannoahsilver...@ucla.edu wrote:
Hi,
Just starting to learn about Rcpp tonight (Using it through the inline library)
I'm attempting to construct a matrix and then fill it with values as I iterate
through my function. The results are wrong. Am I accessing the cells of the
matrix incorrectly?
You are accessing the cells just fine, but you are using the wrong operator.
^ is a bitwise OR in C++
You are in need of the `pow` function, ie:
R library(inline)
R fx- cxxfunction(
signature(),
plugin=Rcpp,
body=
Rcpp::NumericMatrix out_xx(10, 4);
for(int i = 1; i != 10; i++){
out_xx(i,0) = i;
out_xx(i,1) = pow(i,2);
out_xx(i,2) = pow(i,3);
out_xx(i,3) = pow(i,4);
}
return Rcpp::wrap(out_xx);
)
R fx()
[,1] [,2] [,3] [,4]
[1,]0000
[2,]1111
[3,]248 16
[4,]39 27 81
[5,]4 16 64 256
[6,]5 25 125 625
[7,]6 36 216 1296
[8,]7 49 343 2401
[9,]8 64 512 4096
[10,]9 81 729 6561
-steve
The idea was to have an integer in the first position of each row, and then the
polynomials in the subsequent positions.
Any suggestions?
Here is my test code:
Test2- cxxfunction(
signature(),
plugin=Rcpp,
body=
Rcpp::NumericMatrix out_xx(10, 4);
for(int i = 1; i != 10; i++){
out_xx(i,0) = i;
out_xx(i,1) = i^2;
out_xx(i,2) = i^3;
out_xx(i,3) = i^4;
}
return Rcpp::wrap(out_xx);
)
-
Test2()
[,1] [,2] [,3] [,4]
[1,]0000
[2,]1325
[3,]2016
[4,]3107
[5,]4670
[6,]5761
[7,]6452
[8,]7543
[9,]8 10 11 12
[10,]9 11 10 13
--
Noah Silverman
UCLA Department of Statistics
8117 Math Sciences Building #8208
Los Angeles, CA 90095
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
--
Romain François
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
