Re: [Rcpp-devel] Code review for xtensor R bindings

[Romain Francois]

Hi, 

Instead of doing that: 

const int vtype = traits::r_sexptype_traits::rtype;
SEXP shape_sxp = Rf_allocVector(vtype, shape.size());

Perhaps your rxarray object could hold an IntegerVector. Also not quite sure 
why you use the first line at all, which does not depend on T, so vtype is 
always going to be INTSXP. 


Also, you should avoid using std::cout in 
https://github.com/QuantStack/xtensor-r/blob/master/src/rcpp_hello_xtensor.cpp#L14
 


You can use Rcpp::Rcout instead, or Rprintf. 

> And the memory is going to be freed again, at some point. And calling 
> Rcpp_ReleaseObject(m_sexp) would also clear the shape_sxp "attribute", right?


The shape_sxp object you create here (and don’t protect)
https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L152
 


Is probably duplicated here: 
https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L160
 


As part of allocArray’s business: 
https://github.com/wch/r-source/blob/d60c742aa8acc764874db87e3c748e27986e1134/src/main/array.c#L259
 


Romain



> Le 7 juin 2017 à 03:01, Wolf Vollprecht  a écrit :
> 
> Ok, I think I got the idea. 
> 
> In the R->xtensor bindings, we always work directly on memory allocated 
> through R (either passed in from R or allocated from C++ code).
> 
> The review-relevant lines are really only ~10 lines: 
> https://github.com/QuantStack/xtensor-r/blob/master/inst/include/xtensor-r/rxarray.hpp#L145
>  
> 
> 
> const int vtype = traits::r_sexptype_traits::rtype;
> SEXP shape_sxp = Rf_allocVector(vtype, shape.size());
> 
> int* r_shape = INTEGER(shape_sxp);
> // set shape values ... 
> m_sexp = Rf_allocArray(SXP, shape_sxp);
> 
> So afterwards, the idea would be to make a call to 
> 
> Rcpp_PreserveObject(m_sexp);
> 
> right? And if the destructor of the object is called (and the object is owned 
> from C++) we would just call 
> 
> Rcpp_ReleaseObject(m_sexp);
> 
> And the memory is going to be freed again, at some point. And calling 
> Rcpp_ReleaseObject(m_sexp) would also clear the shape_sxp "attribute", right?
> 
> Thanks for your reply! 
> 
> Wolf
> 
> 
> 2017-06-06 16:27 GMT-07:00 Dirk Eddelbuettel  >:
> 
> On 6 June 2017 at 17:06, Dirk Eddelbuettel wrote:
> | The general idea when working with R objects is that
> |
> |   -- on the way in from R to the C++ functions we construct object such that
> |  the existing memory (from R) is used; one example is how RcppArmadillo
> |  uses the 'advanced' constructors of Armadillo allowing to operate
> |  without copies; hence R managed memory is used while C++ functions are
> |  called; in general this side of the conversion is the templates as<>()
> |  converters;
> |
> |   -- on the way back we use the *alloc functions from the C-level API of R 
> to
> |  construct objects that use memory from R's pool, once we return these
> |  objects to R as SEXP they are indistinguishable to R from its own; 
> these
> |  are the wrap() functions (and I think we may make on occassion make 
> "one
> |  final copy" at his level, but I'd have to double-check).
> 
> Actually, let me rephrase: "in most cases not involving native R types" do we
> make one copy at the return.
> 
> The general approach is iterator based, see internal/wrap.h. But there is a
> lot of template magic...
> 
> Dirk
> 
> | I haven't had a chance to look at what Wes is doing with Apache Arrow, and
> | what is happening with xtensor -- so thanks for getting the ball rolling.
> |
> | 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 
> 
> 
> --
> 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

Re: [Rcpp-devel] starter

[Romain Francois]

This looks like a copy and paste mistake. I can definitely see this line on the 
slide 57: 
RMatrix output; 

Anyway, the example is there: 
http://gallery.rcpp.org/articles/parallel-matrix-transform/ 
<http://gallery.rcpp.org/articles/parallel-matrix-transform/>

Romain

> Le 31 mai 2017 à 12:42, f.k...@mailbox.org a écrit :
> 
> Thanks Romain,
> 
> this error is fine now, however, now I run into new…
> I took the example code from this 
> <http://dirk.eddelbuettel.com/papers/rcpp_rfinance_may2015.pdf> presentation 
> of Dirk
> 
> 
> > Rcpp::sourceCpp("src/par_example.cpp")
> par_example.cpp:26:21: error: member initializer 'output' does not name a 
> non-static data member or base class
> : input(input), output(output) {}
> ^~
> par_example.cpp:31:5: error: use of undeclared identifier 'output'
> output.begin() + begin,
> ^
> 2 errors generated.
> make: *** [par_example.o] Error 1
> 
> 
> Hope this is as easily solved as the before error.
> 
> Cheers, Franz
> 
> 
> 
> 
>> On 31 May 2017, at 12:26, Romain Francois <rom...@r-enthusiasts.com 
>> <mailto:rom...@r-enthusiasts.com>> wrote:
>> 
>> You can add this somewhere on top of your cpp file 
>> 
>> // [[Rcpp::depends(RcppParallel)]]
>> 
>> Romain
>> 
>>> Le 31 mai 2017 à 12:22, f.k...@mailbox.org <mailto:f.k...@mailbox.org> a 
>>> écrit :
>>> 
>>> Hi all,
>>> 
>>> I am very new to Rcpp and I wrote a function which I now want to 
>>> parallelize.
>>> The function is working fine, and is much faster than in R, however, it 
>>> really is slow for bigger datasets.
>>> 
>>> Since the function is running I don’t need to explain what it does, 
>>> however, it is has 
>>> 3 nested for loops. It loops through columns and within each column if 
>>> loops through the rows and in a third loop produces pair comparisons… 
>>> 
>>> So the parallelisation should parallelize the column loop.
>>> 
>>> I found the RcppParallel package and for the beginning wanted to run on of 
>>> the example to understand the
>>> workflow first. However, I already have issues running the code below:
>>> 
>>> following is sourced with: Rcpp::sourceCpp("src/par_example.cpp")
>>> However, I get the error: 
>>> 
>>> par_example.cpp:6:10: fatal error: 'RcppParallel.h' file not found
>>> #include 
>>>  ^
>>> 1 error generated.
>>> make: *** [par_example.o] Error 1
>>> 
>>> I would much appreciate if someone could give me a start with this!
>>> 
>>> Cheers, 
>>> Franz
>>> 
>>> 
>>> 
>>> #include 
>>> 
>>> using namespace Rcpp;
>>> #include 
>>> #include 
>>> #include 
>>> 
>>> // [[Rcpp::export]]
>>> NumericMatrix matrixSqrt(NumericMatrix orig) {
>>>   // allocate the matrix we will return
>>>   NumericMatrix mat(orig.nrow(), orig.ncol());
>>>   // transform it
>>>   std::transform(orig.begin(), orig.end(), mat.begin(), ::sqrt);
>>>   // return the new matrix
>>>   return mat;
>>> }
>>> 
>>> 
>>> using namespace RcppParallel;
>>> struct SquareRoot : public Worker {
>>>   const RMatrix input;
>>>   // source matrix RMatrix output; // destination matrix
>>>   // initialize with source and destination
>>>   SquareRoot(const NumericMatrix input, NumericMatrix output)
>>> : input(input), output(output) {}
>>>   // take the square root of the range of elements requested
>>>   void operator()(std::size_t begin, std::size_t end) { 
>>> std::transform(input.begin() + begin,
>>> input.begin() + end,
>>> output.begin() + begin,
>>> ::sqrt);
>>>   }
>>> };
>>> 
>>> // [[Rcpp::export]]
>>> NumericMatrix parallelMatrixSqrt(NumericMatrix x) {
>>>   // allocate the output matrix
>>>   NumericMatrix output(x.nrow(), x.ncol());
>>>   // SquareRoot functor (pass input and output matrixes)
>>>   SquareRoot squareRoot(x, output);
>>>   // call parallelFor to do the work
>>>   parallelFor(0, x.length(), squareRoot);
>>>   // return the output matrix
>>>   return output; }
>>> 
>>> 
>>> 
>>> ___
>>> 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 
>>> <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] starter

[Romain Francois]

You can add this somewhere on top of your cpp file 

// [[Rcpp::depends(RcppParallel)]]

Romain

> Le 31 mai 2017 à 12:22, f.k...@mailbox.org a écrit :
> 
> Hi all,
> 
> I am very new to Rcpp and I wrote a function which I now want to parallelize.
> The function is working fine, and is much faster than in R, however, it 
> really is slow for bigger datasets.
> 
> Since the function is running I don’t need to explain what it does, however, 
> it is has 
> 3 nested for loops. It loops through columns and within each column if loops 
> through the rows and in a third loop produces pair comparisons… 
> 
> So the parallelisation should parallelize the column loop.
> 
> I found the RcppParallel package and for the beginning wanted to run on of 
> the example to understand the
> workflow first. However, I already have issues running the code below:
> 
> following is sourced with: Rcpp::sourceCpp("src/par_example.cpp")
> However, I get the error: 
> 
> par_example.cpp:6:10: fatal error: 'RcppParallel.h' file not found
> #include 
>  ^
> 1 error generated.
> make: *** [par_example.o] Error 1
> 
> I would much appreciate if someone could give me a start with this!
> 
> Cheers, 
> Franz
> 
> 
> 
> #include 
> 
> using namespace Rcpp;
> #include 
> #include 
> #include 
> 
> // [[Rcpp::export]]
> NumericMatrix matrixSqrt(NumericMatrix orig) {
>   // allocate the matrix we will return
>   NumericMatrix mat(orig.nrow(), orig.ncol());
>   // transform it
>   std::transform(orig.begin(), orig.end(), mat.begin(), ::sqrt);
>   // return the new matrix
>   return mat;
> }
> 
> 
> using namespace RcppParallel;
> struct SquareRoot : public Worker {
>   const RMatrix input;
>   // source matrix RMatrix output; // destination matrix
>   // initialize with source and destination
>   SquareRoot(const NumericMatrix input, NumericMatrix output)
> : input(input), output(output) {}
>   // take the square root of the range of elements requested
>   void operator()(std::size_t begin, std::size_t end) { 
> std::transform(input.begin() + begin,
> input.begin() + end,
> output.begin() + begin,
> ::sqrt);
>   }
> };
> 
> // [[Rcpp::export]]
> NumericMatrix parallelMatrixSqrt(NumericMatrix x) {
>   // allocate the output matrix
>   NumericMatrix output(x.nrow(), x.ncol());
>   // SquareRoot functor (pass input and output matrixes)
>   SquareRoot squareRoot(x, output);
>   // call parallelFor to do the work
>   parallelFor(0, x.length(), squareRoot);
>   // return the output matrix
>   return output; }
> 
> 
> 
> ___
> 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 sugar for double?

[Romain Francois]

Hello, 

Functions in sugar only apply to vectors. 

For a single value, you’d have to use the dnorm function in the R:: namespace: 

// [[Rcpp::export]]
double test6(double x){
  double y = R::dnorm(x,5.0,2.0,true);
  return y;
}

> test6(3)
[1] -2.112086

> dnorm(3, mean = 5, sd = 2, log = TRUE)
[1] -2.112086


Romain


> Le 22 févr. 2017 à 15:58, Eridk Poliruyt  a écrit :
> 
> Hi, I just tried to calculate the density of a normal variable using dnorm. I 
> found that if the input is of type NumericVector, then it was fine. But if 
> the input is of type double, it yielded error in compilation. For example:
> 
>  // [[Rcpp::export]]
> NumericVector test5(NumericVector x)
> {
>   NumericVector y = dnorm(x,5.0,2.0,true);
>   return(y);
> }
> 
> and
> 
> // [[Rcpp::export]]
> double test6(double x)
> {
>   double y = dnorm(x,5.0,2.0,true);
>   return(y);
> }
> 
> May I ask why and how can I calculate this density (and call other common 
> functions like dbeta, dt, beta, gamma, lbeta, lgamma, etc...) on double input?
> 
> Many thanks,
> Eridk
> ___
> 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 Timer

[Romain Francois]

It made more sense to track times since an origin, esp when you might use 
several timers in case you use multiple threads. 


> Le 30 déc. 2016 à 13:37, Dirk Eddelbuettel <e...@debian.org> a écrit :
> 
> 
> On 29 December 2016 at 11:25, Jonathan Christensen wrote:
> | Hi Kaspar and Dirk,
> | 
> | It is indeed cumulative. Previously (presumably when that gallery page was
> | written) it was not cumulative, but Romain Francois changed the behavior of 
> the
> | step() function several years ago, in this commit: 
> https://github.com/RcppCore/
> | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1.
> 
> Nice catch.
> 
> | There is no indication or reasoning about changing the behavior, so it may 
> be
> | that making it cumulative was unintentional.
> 
> Let's presume it was intentional to the author of the change -- but as you
> rightly point out, it did of course change and reverse previous behaviour.
> 
> We could easily add a toggle to the constructor to get an either/or behaviour.
> 
> 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 ISNAN slower than C ISNAN?

[Romain Francois]

I’d be interesting to see what this more C++idomatic version would perform 

nanCount = std::count_if( x.begin(), x.end(), ISNAN ) ;

Because despite all the inlining efforts that has been put in the 
implementation of NumericVector, its operator[] might not perform as well as 
using [] on a double*. 

Romain


> Le 13 déc. 2016 à 12:38, Johannes Kruisselbrink  a 
> écrit :
> 
> Here is a further reduced example (see below). Now it is a function to count 
> NaNs in a vector, and it shows the same behaviour. Code is also available at 
> https://github.com/jwkruisselbrink/rcpp-timings/tree/master/minimal.
> 
> Regarding your question:
> | Why not drop data and codes and use  sData1(i,k) - sData2(j,k)
> 
> Well, I wanted to rule out that Rcpp sugar was causing the slowdown. If it 
> isn't we'll put it back in after having a fix for this issue.
> 
> /=== call.c ===/
> 
> #include 
> #include 
> 
> SEXP CountNans(SEXP sX, SEXP sLength) {
>  int i, n = *INTEGER(sLength);
>  int *nanCount;
>  double *x = REAL(sX);
> 
>  SEXP output = PROTECT(allocVector(INTSXP, 1));
>  nanCount = INTEGER(output);
>  *nanCount = 0;
>  for (i = 0; i < n; i++) {
>if (ISNAN(x[i])) {
>  *nanCount += 1;
>}
>  }
>  UNPROTECT(1);
>  return output;
> }
> 
> /=== rcpp.cpp ===/
> 
> #include 
> #include 
> using namespace Rcpp;
> 
> // [[Rcpp::export]]
> int CountNans(NumericVector x) {
>  int n = x.length();
>  int nanCount = 0;
>  for (int i = 0; i < n; i++) {
>if (ISNAN(x[i])) {
>  nanCount++;
>}
>  }
>  return nanCount;
> }
> 
> /=== R code ===/
> 
> library(Rcpp)
> library(microbenchmark)
> library(ggplot2)
> 
> sourceCpp('rcpp.cpp')
> 
> if (is.loaded(paste("call", .Platform$dynlib.ext, sep=""))) {
>  dyn.unload(paste("call", .Platform$dynlib.ext, sep=""))
> }
> system(paste("R CMD SHLIB call.c", sep=""))
> dyn.load(paste("call", .Platform$dynlib.ext, sep=""))
> 
> n <- as.integer(10)
> x <- rnorm(n)
> mb <- microbenchmark(
>  rcpp <- CountNans(x),
>  call <- .Call("CountNans", x, n),
>  times = 1
> )
> 
> autoplot(mb)
> 
> 
> ___
> 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] Specify Rcpp header location in Makevars

[Romain Francois]

You need 

LinkingTo: Rcpp

As per the current documentation. 

Romain

Envoyé de mon iPhone

 Le 29 juil. 2015 à 17:19, jsmith5...@yahoo.com jsmith5...@yahoo.com a 
 écrit :
 
 Hi,
 
 Is there a way to automatically specify the location of the Rcpp include
 directory (for Rcpp.h) in Makevars?
 
 In my Makevars, I use the following compile command:
 
 %.o: %.cpp $(cpp_sources)
$(CXX) $(PKG_CXXFLAGS) $
 
 
 I also specified Imports: Rcpp in DESCRIPTION, but it does not appear
 to automatically add the right flags to the compile command.
 
 I am looking for something that could work similarly to Rscript -e
 Rcpp:::LdFlags(), which used to export the Rcpp library flags.
 
 Any ideas are greatly appreciated!
 
 Thanks!
 Lutz
 ___
 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] When calling same Rcpp function several times different results are returned

[Romain Francois]

Or just use a std::vectordouble for sg. That should do it. 

Romain

Envoyé de mon iPhone

 Le 14 juil. 2015 à 13:21, JJ Allaire jj.alla...@gmail.com a écrit :
 
 The examples in the RcppParallel documentation assume that access to
 vectors and matrixes are *aligned* (i.e. fall into neat buckets
 whereby reading and writing doesn't overlap between worker instances).
 Your example appears to access arbitrary elements of sg (depending on
 what's passed in gi) which probably creates overlapping reads/writes.
 You should also study the documentation for join carefully.
 
 There's nothing incorrect about RcppParallel's behavior here, rather
 you need to think more carefully about the access patterns of your
 data and how they might conflict. You may need to introduce locking to
 overcome the conflicts, which in turn could kill the performance
 benefit you gain from parallelism. No easy answers here :-\
 
 On Tue, Jul 14, 2015 at 7:15 AM, Danas Zuokas danas.zuo...@gmail.com wrote:
 Yes it is the same question on SO and I did consider RHertel's comments.
 But this problem (sums by group id) is not parallelFor it is parallelReduce:
 I split vector, calculate sums and then aggregate those sums.
 Please correct me if I am wrong.
 
 2015-07-14 13:54 GMT+03:00 Dirk Eddelbuettel e...@debian.org:
 
 
 On 14 July 2015 at 09:25, Danas Zuokas wrote:
 | I have written parallel implementation of sums in groups using
 RcppParallel.
 
 Isn't this the same question as
 
 http://stackoverflow.com/questions/31318419/when-calling-same-rcpp-function-several-times-different-results-are-returned
 
 You got some excellent comments there by SO user 'RHertel'. Did you
 consider those?
 
 Dirk
 
 | // [[Rcpp::depends(RcppParallel)]]
 | #include Rcpp.h
 | #include RcppParallel.h
 | using namespace Rcpp;
 | using namespace RcppParallel;
 |
 | struct SumsG: public Worker
 | {
 |   const RVectordouble v;
 |   const RVectorint gi;
 |
 |   RVectordouble sg;
 |
 |   SumsG(const NumericVector v, const IntegerVector gi, NumericVector
 sg): v(v), gi(gi), sg(sg) {}
 |   SumsG(const SumsG p, Split): v(p.v), gi(p.gi), sg(p.sg) {}
 |
 |   void operator()(std::size_t begin, std::size_t end) {
 | for (std::size_t i = begin; i  end; i++) {
 |   sg[gi[i]] += v[i];
 | }
 |   }
 |
 |   void join(const SumsG p) {
 | for(std::size_t i = 0; i  sg.length(); i++) {
 |   sg[i] += p.sg[i];
 | }
 |   }
 | };
 |
 | // [[Rcpp::export]]
 | List sumsingroups(NumericVector v, IntegerVector gi, int ni) {
 |   NumericVector sg(ni);
 |   SumsG p(v, gi, sg);
 |   parallelReduce(0, v.length(), p);
 |
 |   return List::create(_[sg] = p.sg);
 | }
 |
 | It compiles using Rcpp::sourceCpp. Now when I call it from R
 sumsingroups(1:10,
 | rep(0:1, each = 5), 2) several times I get the right answer (15 40) and
 then
 | something different (usually some multiplicative of the right answer).
 Running
 |
 |
 | res - sumsingroups(1:10, rep(0:1, each = 5), 2)
 | for(i in 1:1000) {
 | tmp - sumsingroups(1:10, rep(0:1, each = 5), 2)
 | if(res[[1]][1] != tmp[[1]][1]) break
 | Sys.sleep(0.1)
 | }
 |
 | breaks at random iteration returning
 |
 | $sg
 | [1]  60 160
 |
 | or
 |
 | $sg
 | [1] 30 80
 |
 | I am new to Rcpp and RcppParallel and do not know what could cause such
 | behavior.
 |
 | Things that did not help:
 |
 |  1. Added for (std::size_t i = 0; i  sg.length(); i++) sg[i] = 0; to
 both of
 | constructors.
 |  2. Changed names so that they are different in Worker definition and in
 | function implementation.
 |
 | ___
 | 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
 
 --
 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
___
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] On Developing Header Packages

[Romain Francois]

I would definitely second that. This eliminates a whole class of hard to deal 
with issues. 

Even Rcpp IMO should really just be header only. 

Romain

Envoyé de mon iPhone

 Le 7 avr. 2015 à 20:51, JJ Allaire jj.alla...@gmail.com a écrit :
 
 I think that header-only packages (where possible) are definitely
 preferable within the R package ecosystem because it allows you to
 sidestep a lot of build configuration and runtime linking complexity.
 
 The rub is that some libraries simply can't be made header-only,
 especially if they make use of static data. I was able to convert the
 TinyThread library to header-only by simply prefacing all
 function/method definitions with the inline keyword. However that was
 a pretty small library so I'm not sure you'd have the same easy time
 of it with a larger library like clBLAS.
 
 
 On Tue, Apr 7, 2015 at 2:37 PM, Charles Determan cdeterma...@gmail.com 
 wrote:
 This is probably the best place I can think of to ask this question if
 perhaps not completely on topic.  Some quick context:
 
 I am exploring GPGPU computing and with my 'open-source' mindset I quickly
 gravitated to using OpenCL.  Thankfully, many wonderful programmers have
 already begun creating libraries to make this language better and faster.
 One such library is the clBLAS library which essentially implements BLAS
 routines for OpenCL enabled devices. Naturally, I would like to use this
 library but I don't like the idea of telling users to install a dependency
 outside of R and would rather have them install another package.  Therefore,
 I have it in my head to create a header package for the clBLAS library to be
 used by anyone exploring OpenCL programming within R.
 
 This leads me to my two general questions that I hope others can comment.
 
 1.  What are developers thoughts regarding the 'packaging' of various C++
 header libraries?  I know this has be very successfully done with the 'BH'
 package but is this considered an exception or an example?
 
 2. If it is encouraged to create such header packages are there any
 guidelines or standards that should be followed?  Is there an expected
 structure?  I can look at the 'BH' package and go from there but it would be
 nice if the R(cpp) community had some collective opinion about this.
 
 Regards,
 Charles
 
 ___
 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] assert() for Rcpp?

[Romain Francois]

Envoyé de mon iPhone

 Le 18 févr. 2015 à 17:31, JJ Allaire jj.alla...@gmail.com a écrit :
 
 We *can* call Rf_error from C++ code, but when we do it bypasses all
 C++ destructors on the stack, so we don't do it so as not leak memory
 and otherwise have deterministic behavior around
 construction/destruction.
 
 You'll notice in Dirk's example that there are no C++ objects on the
 stack when he calls Rf_error.

This would still bypass the dror for the RNGscope object automatically added by 
Rcpp::export right ?

 The core idea in Rcpp is to use
 exceptions to get high enough in the stack that there are no more
 destructors.
 
 On Wed, Feb 18, 2015 at 9:08 AM, Sparapani, Rodney rspar...@mcw.edu wrote:
 On Tue, 2015-02-17 at 17:53 -0700, JJ Allaire wrote:
 One piece of immediate feedback on your initial implementation: you
 can't call Rf_error from C++ code (as it will bypass C++ destructors
 on the stack). Rather, you should throw Rcpp::exception.
 
 Hi JJ:
 
 Ok, this puzzles me.  We can't call Rf_error from C++ code, but we can
 call it from within the exception handler, right?  It would seem so
 since Dirk has written a nice gallery post that does it that way...
 http://gallery.rcpp.org/articles/intro-to-exceptions
 
 Just my $0.02, but I would stick to exceptions and avoid assert in C++.
 
 Rodney
 
 
 
 ___
 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] String encoding (UTF-8 conversion)

[Romain Francois]

That is similar to a path i've followed in Rcpp11/Rcpp14.

What's really missing in R is api access to strings, e.g testing for equality 
of two CHARSXP, comparing them, ...

This causes all sorts of problems with dplyr. 

Romain

 Le 16 déc. 2014 à 06:00, Jeroen Ooms jeroen.o...@stat.ucla.edu a écrit :
 
 On Thu, Dec 11, 2014 at 12:24 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu 
 wrote:
 I'm interfacing a c++ library which assumes strings are UTF-8. However
 strings from R can have various encodings. It's not clear to me how I
 need to account for that in Rcpp.
 
 Follow-up on this: from what I have found, there is currently no
 string type that is unambiguous across platforms and locales (other
 than the actual STRSXP). If the native locale uses UTF8 than all is
 fine, but we can not assume that in R. Here is a little script that
 illustrates the various combinations I tried and the results on
 Windows: https://gist.github.com/jeroenooms/9edf97f873f17a4ce5d3.
 
 Assuming that each of these cases are intended behavior, perhaps we
 could introduce an additional string type e.g. Rcpp::UTF8String. The
 mapping from STRSXP to Rcpp::UTF8String would use
 translateCharUTF8(STRING_ELT(x, 0)) and the mapping Rcpp::UTF8String
 back to STRSXP would use SET_STRING_ELT(out, 0, mkCharCE(olds,
 CE_UTF8)). That would allow for defining c++ functions operating on
 UTF8 strings which will work as expected across platforms and locales.
 ___
 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

[Romain Francois]

Envoyé de mon iPhone

 Le 3 déc. 2014 à 17:59, Gabor Grothendieck ggrothendi...@gmail.com a écrit :
 
 1. This returns a matrix rather than a vector:
 
 --  start of file teste.cpp ---
 #include RcppArmadillo.h
 // [[Rcpp::depends(RcppArmadillo)]]
 
 using namespace arma;
 using namespace Rcpp;
 
 // [[Rcpp::export]]
 NumericVector teste(const vec x) {
 vec v = x.subvec(1, 2); // x
 return wrap(v); // x
 }
 /*** R
 teste(1:4)
 */
 --- end of file teste.cpp ---
 
 Now run in R:
 
 sourceCpp(teste.cpp, rebuild = TRUE)
 
 teste(1:4)
 [,1]
 [1,]2
 [2,]3
 
 
 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. 

Romain

 
 -- 
 Statistics  Software Consulting
 GKX Group, GKX Associates Inc.
 tel: 1-877-GKX-GROUP
 email: ggrothendieck at gmail.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
___
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

[Romain Francois]

This is probably related to this: 


template int RTYPE
struct r_vector_const_iterator {
typedef typename storage_typeRTYPE::type* type ;
};

There should be a const there somewhere. 

FWIW, more modern implementations of R/C++ are more safe on that issue: 

$ Rcpp11Script /tmp/martyn.cpp
file33e7a74d9ba.cpp:18:33: error: cannot initialize a variable of type 
'NumericVector::iterator' (aka 'double *') with an rvalue of
  type 'const_iterator' (aka 'const double *')
   for (NumericVector::iterator i = v.begin(); i != v.end(); ++i) {
^   ~
1 error generated.
make: *** [file33e7a74d9ba.o] Error 1
Error in dyn.load(basename(dynlib)) :
  unable to load shared object 
'/private/var/folders/k8/gmp11jks4hl_nwcnk82fbr8mgn/T/RtmpKvVUpq/file33e7a74d9ba.so':
  
dlopen(/private/var/folders/k8/gmp11jks4hl_nwcnk82fbr8mgn/T/RtmpKvVUpq/file33e7a74d9ba.so,
 6): image not found
Calls: sourceCpp - Anonymous - dyn.load
In addition: Warning message:
running command '/Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB 
'file33e7a74d9ba.cpp'' had status 1
Execution halted


If I change NumericVector::iterator to auto, I then get: 

$ Rcpp11Script /tmp/martyn.cpp
file34f617c08b2.cpp:19:16: error: binding of reference to type 'double' to a 
value of type 'const double' drops qualifiers
   double x = *i;
   ^   ~~
1 error generated.
make: *** [file34f617c08b2.o] Error 1
Error in dyn.load(basename(dynlib)) :
  unable to load shared object 
'/private/var/folders/k8/gmp11jks4hl_nwcnk82fbr8mgn/T/Rtmp74ZJLp/file34f617c08b2.so':
  
dlopen(/private/var/folders/k8/gmp11jks4hl_nwcnk82fbr8mgn/T/Rtmp74ZJLp/file34f617c08b2.so,
 6): image not found
Calls: sourceCpp - Anonymous - dyn.load
In addition: Warning message:
running command '/Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB 
'file34f617c08b2.cpp'' had status 1
Execution halted

Hard compiler error/GOOD THING. 


 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] Indexing vector with x(i) and x[i] gives remarkable difference in computing time

[Romain Francois]

 Le 27 nov. 2014 à 13:22, Søren Højsgaard sor...@math.aau.dk a écrit :
 
 Dear all,
 By accident I noticed that indexing with x(i) and x[i] gives remarkable 
 difference in computing time. For example:
 
 library(Rcpp)
 cppFunction('
 IntegerVector insert1 (int n){
  IntegerVector z(n);
  for (int i=0; in; ++i) z(i) = i;  // NOTICE: using ()
  return z;
 }')
 cppFunction('
 IntegerVector insert2 (int n){
  IntegerVector z(n);
  for (int i=0; in; ++i) z[i] = i;  // NOTICE: using []
  return z;
 }')
 
 Both functions work:
 n - 10; insert1(n); insert2(n)
 [1] 0 1 2 3 4 5 6 7 8 9
 [1] 0 1 2 3 4 5 6 7 8 9
 
 But notice this difference in computing time:
 n - 5
 microbenchmark::microbenchmark( insert1(n), insert2(n) )
 Unit: microseconds
   expr min   lq mean   median   uq  max neval cld
 insert1(n) 391.154 406.5500 416.9694 407.5005 421.1855  731.752   100   b
 insert2(n) 149.771 156.8045 189.9401 157.3745 163.0760 1204.635   100  a
 
 So using z(i) is more than twice as slow as using z[i].
 
 This prompts me to ask:
 1) Why is that?

bounds checking. operator()(int i) checks that is i is between 0 and the length 
of the vector. 

 2) In the vignettes it is always [i] that are used for vectors. But why is it 
 that (i,j) is then used for matrices. Wouldn't it be preferable if one could 
 use both [] and () for indexing in both cases (and with the same speed) - or 
 are there deeper reasons for this?

No such thing as a operator[](int, int) in C++ so we had to use ()

 
 Best regards
 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] sugar: x+y and y+x gives different results when there are NA's in y

[Romain Francois]

This has nothing to do with NA. It's just about the size difference. sugar does 
not make attempt at recycling. Your responsibility. 

Romain

 Le 22 nov. 2014 à 11:48, Søren Højsgaard sor...@math.aau.dk a écrit :
 
 Dear all,
 Came across this:
 
 #include Rcpp.h
 using namespace Rcpp;
 
 //[[Rcpp::export]]
 List  sumxy(NumericVector x, NumericVector y){
  NumericVector xy = x+y;
  NumericVector yx = y+x;
  return List::create(xy, yx);
 }
 
 /*** R
 x - c(1,3,5,7)
 y - c(NA,2,4,6,8)
 x+y
 y+x
 sumxy(x, y)
 */
 
 x - c(1,3,5,7)
 y - c(NA,2,4,6,8)
 x+y
 [1] NA  5  9 13  9
 y+x
 [1] NA  5  9 13  9
 sumxy(x, y)
 [[1]]
 [1] NA  5  9 13
 [[2]]
 [1] NA  5  9 13  8
 
 Is this intentional? Apologies if this has been documented anywhere; was 
 unable to find it.
 
 Regards
 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] sugar: x+y and y+x gives different results when there are NA's in y

[Romain Francois]

You get UB if the first is bigger than the second. 

Envoyé de mon iPhone

 Le 22 nov. 2014 à 14:30, Søren Højsgaard sor...@math.aau.dk a écrit :
 
 OK; thanks! Shall I read this such as the behaviour is undefined?
 Søren
 
 |-Original Message-
 |From: Romain Francois [mailto:rom...@r-enthusiasts.com]
 |Sent: 22. november 2014 13:25
 |To: Søren Højsgaard
 |Cc: rcpp-devel@lists.r-forge.r-project.org
 |Subject: Re: [Rcpp-devel] sugar: x+y and y+x gives different results when
 |there are NA's in y
 |
 |This has nothing to do with NA. It's just about the size difference.
 |sugar does not make attempt at recycling. Your responsibility.
 |
 |Romain
 |
 | Le 22 nov. 2014 à 11:48, Søren Højsgaard sor...@math.aau.dk a écrit :
 |
 | Dear all,
 | Came across this:
 |
 | #include Rcpp.h
 | using namespace Rcpp;
 |
 | //[[Rcpp::export]]
 | List  sumxy(NumericVector x, NumericVector y){  NumericVector xy =
 | x+y;  NumericVector yx = y+x;  return List::create(xy, yx); }
 |
 | /*** R
 | x - c(1,3,5,7)
 | y - c(NA,2,4,6,8)
 | x+y
 | y+x
 | sumxy(x, y)
 | */
 |
 | x - c(1,3,5,7)
 | y - c(NA,2,4,6,8)
 | x+y
 | [1] NA  5  9 13  9
 | y+x
 | [1] NA  5  9 13  9
 | sumxy(x, y)
 | [[1]]
 | [1] NA  5  9 13
 | [[2]]
 | [1] NA  5  9 13  8
 |
 | Is this intentional? Apologies if this has been documented anywhere;
 |was unable to find it.
 |
 | Regards
 | 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

Re: [Rcpp-devel] inplace modification more affect other varibles

[Romain Francois]

a and b are the same object: 

 a - seq(1, 0.1, -0.1)
 b - a
 pryr::address( a )
[1] 0x7f9504534948
 pryr::address( b )
[1] 0x7f9504534948

So clone is what you need here. 

Implementing copy on write for that kind of example is possible, but would 
require a lot of additional code, i.e. the iterator would need to handle the 
write operation. 

An undesirable side effect of this is that such iterators would be quite less 
performant, right now Rcpp is close to the metal and uses direct pointers as 
iterators when it makes sense. A price that everyone would have to pay. no go. 

Instead, the responsibility is given to the user to clone explicitly when 
changes will be made to the underlying object. 

Romain 


 Le 22 oct. 2014 à 04:13, Chenliang Xu luckyr...@gmail.com a écrit :
 
 Hi Dirk,
 
 Thanks for your quick answer. I don't think Rcpp::clone is what I was looking 
 for. I know `stl_sort_inplace(a)` modify the value of `a`, but it surprise me 
 to see it modify `b`. And it may modify some other variables c, d, e, f..., 
 and it's hard to know which variables point to the same place.
 
 On Tue, Oct 21, 2014 at 8:31 PM, Dirk Eddelbuettel e...@debian.org 
 mailto:e...@debian.org wrote:
 
 On 21 October 2014 at 20:22, Chenliang Xu wrote:
 | Hello,
 |
 | With the following inplace sorting example, I understand the value of `a` is
 | sorted inplace, but it's strange to see the value of `b` is also modified. 
 This
 | can cause some hard to detect bug, since the cpp function may modify a 
 variable
 | defined in other scope.
 
 Very well known issue -- maybe do a search for 'Rcpp::clone' ...
 
 In a nutshell, SEXP objects are passed by a __pointer__ and changes do
 therefore persist.  If you want distinct copies, use Rcpp::clone().
 
 Dirk
 
 | It seems that rcpp doesn't respect the named field, which is adopted by R to
 | implement copy-on-modify. I don's see an easy fix on C++ side, since the 
 called
 | cpp function has no information about variable binding in R. A possible fix 
 is
 | adding a function `inplace` to R, which ensure the returned variable has 
 named
 | filed = 0 so is safe to modify inplace. Then, we have to call the function 
 as
 | `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. It
 | shows clearly that we are breaking the pass-by-value rule in R.
 |
 | ```cpp
 | #include Rcpp.h
 | using namespace Rcpp;
 |
 | // [[Rcpp::export]]
 | void stl_sort_inplace(NumericVector x) {
 | std::sort(x.begin(), x.end());
 | }
 |
 | ```
 |
 | ```r
 | a - seq(1, 0.1, -0.1)
 | b - a
 | #  [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1
 |
 | stl_sort_inplace(a)
 |
 | a
 | #  [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
 |
 | b
 | #  [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
 |
 | a - seq(1, 0.1, -0.1)
 | pure_function - function (x) {
 |   y - x
 |   stl_sort_inplace(y)
 |   print(y)
 | }
 | pure_function(a)
 | a
 | #  [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
 |
 | ```
 |
 | ___
 | 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 
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 --
 http://dirk.eddelbuettel.com http://dirk.eddelbuettel.com/ | @eddelbuettel 
 | e...@debian.org mailto: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] inplace modification more affect other varibles

[Romain Francois]

Pretty much. But sometimes that's what you want, and Rcpp does not get in the 
way. You just have to know the rules of the game. 
BTW, same rules apply when you use .Call C/R API, you are in charge of making 
the copy when it's needed. 

Romain

 Le 22 oct. 2014 à 17:53, Chenliang Xu luckyr...@gmail.com a écrit :
 
 Thanks a lot!
 
 Does that mean we should never modify an argument passed from R to cpp?
 
 On Wed, Oct 22, 2014 at 8:24 AM, Romain Francois rom...@r-enthusiasts.com 
 mailto:rom...@r-enthusiasts.com wrote:
 a and b are the same object: 
 
  a - seq(1, 0.1, -0.1)
  b - a
  pryr::address( a )
 [1] 0x7f9504534948
  pryr::address( b )
 [1] 0x7f9504534948
 
 So clone is what you need here. 
 
 Implementing copy on write for that kind of example is possible, but would 
 require a lot of additional code, i.e. the iterator would need to handle the 
 write operation. 
 
 An undesirable side effect of this is that such iterators would be quite less 
 performant, right now Rcpp is close to the metal and uses direct pointers as 
 iterators when it makes sense. A price that everyone would have to pay. no 
 go. 
 
 Instead, the responsibility is given to the user to clone explicitly when 
 changes will be made to the underlying object. 
 
 Romain 
 
 
 Le 22 oct. 2014 à 04:13, Chenliang Xu luckyr...@gmail.com 
 mailto:luckyr...@gmail.com a écrit :
 
 Hi Dirk,
 
 Thanks for your quick answer. I don't think Rcpp::clone is what I was 
 looking for. I know `stl_sort_inplace(a)` modify the value of `a`, but it 
 surprise me to see it modify `b`. And it may modify some other variables c, 
 d, e, f..., and it's hard to know which variables point to the same place.
 
 On Tue, Oct 21, 2014 at 8:31 PM, Dirk Eddelbuettel e...@debian.org 
 mailto:e...@debian.org wrote:
 
 On 21 October 2014 at 20:22, Chenliang Xu wrote:
 | Hello,
 |
 | With the following inplace sorting example, I understand the value of `a` 
 is
 | sorted inplace, but it's strange to see the value of `b` is also modified. 
 This
 | can cause some hard to detect bug, since the cpp function may modify a 
 variable
 | defined in other scope.
 
 Very well known issue -- maybe do a search for 'Rcpp::clone' ...
 
 In a nutshell, SEXP objects are passed by a __pointer__ and changes do
 therefore persist.  If you want distinct copies, use Rcpp::clone().
 
 Dirk
 
 | It seems that rcpp doesn't respect the named field, which is adopted by R 
 to
 | implement copy-on-modify. I don's see an easy fix on C++ side, since the 
 called
 | cpp function has no information about variable binding in R. A possible 
 fix is
 | adding a function `inplace` to R, which ensure the returned variable has 
 named
 | filed = 0 so is safe to modify inplace. Then, we have to call the function 
 as
 | `stl_sort_inplace(inplace(a))`, which seems odd but is also informative. It
 | shows clearly that we are breaking the pass-by-value rule in R.
 |
 | ```cpp
 | #include Rcpp.h
 | using namespace Rcpp;
 |
 | // [[Rcpp::export]]
 | void stl_sort_inplace(NumericVector x) {
 | std::sort(x.begin(), x.end());
 | }
 |
 | ```
 |
 | ```r
 | a - seq(1, 0.1, -0.1)
 | b - a
 | #  [1] 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1
 |
 | stl_sort_inplace(a)
 |
 | a
 | #  [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
 |
 | b
 | #  [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
 |
 | a - seq(1, 0.1, -0.1)
 | pure_function - function (x) {
 |   y - x
 |   stl_sort_inplace(y)
 |   print(y)
 | }
 | pure_function(a)
 | a
 | #  [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
 |
 | ```
 |
 | ___
 | 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 
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 
 --
 http://dirk.eddelbuettel.com http://dirk.eddelbuettel.com/ | @eddelbuettel 
 | e...@debian.org mailto:e...@debian.org
 
 ___
 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 
 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] convert to unsigned char* variable

[Romain Francois]

 Le 20 oct. 2014 à 21:54, Dirk Eddelbuettel e...@debian.org a écrit :
 
 
 Hi Gustaf,
 
 On 20 October 2014 at 15:17, Gustaf Granath wrote:
 | Im trying to use some C++ functions in R. However, these functions are 
 | build around unsigned char* variables (1D array). I have for example a 
 | large matrix in R that represents black (e.g. 1-bit image, 0 and 1s). I 
 | cant find a solution to convert a character vector into unsigned char* 
 | within Rcpp. Im new to Rcpp and C++ so I might have missed something 
 
 Rcpp builds a bridge between R and C++, and supports (in C++) the types that
 R supports.  Eg you won't find 'float' but only 'double' as that is what R
 does. 
 
 Here you will get character vectors easily. If they must be unsigned char,
 you will probably have to cast them at the C++ level.
 
 | obvious here. Please direct me to resources on this topic (google did 
 | not help much).
 | 
 | A start:
 | 
 | SEXP test(SEXP cM){
 |CharacterVector Vc(cM);
 |int n = Vr.size();
 |RawVector x(n); //is this the same as unsigned char* ?
 
 No, RawVector is for R 'raw' types -- see help(raw) in R,

Guess what raw is !!!

 demangle( RawVector::stored_type )
[1] unsigned char


 Dirk
 
 |  //I tried to fill it with char*(Mr) but I 
 | didnt succeed
 | }
 | 
 | Thanks,
 | 
 | Gustaf
 | 
 | -- 
 | Gustaf Granath (PhD)
 | Post doc
 | McMaster University
 | School of Geography  Earth Sciences
 | 
 | ___
 | 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
 
 -- 
 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] convert to unsigned char* variable

[Romain Francois]

Hi, 

that's not going to fly. 

A CharacterVector holds strings of arbitrary lengths, well technically it holds 
other R objects (SEXP) that hold pointers to strings. 

A RawVector holds unsigned char. 

Can you add some meat to your example, e.g. what you'd expect to go in, etc ... 

Romain

 Le 20 oct. 2014 à 21:17, Gustaf Granath gustaf.gran...@gmail.com a écrit :
 
 Hi
 Im trying to use some C++ functions in R. However, these functions are build 
 around unsigned char* variables (1D array). I have for example a large matrix 
 in R that represents black (e.g. 1-bit image, 0 and 1s). I cant find a 
 solution to convert a character vector into unsigned char* within Rcpp. Im 
 new to Rcpp and C++ so I might have missed something obvious here. Please 
 direct me to resources on this topic (google did not help much).
 
 A start:
 
 SEXP test(SEXP cM){
  CharacterVector Vc(cM);
  int n = Vr.size();
  RawVector x(n); //is this the same as unsigned char* ?
//I tried to fill it with char*(Mr) but I didnt 
 succeed
 }
 
 Thanks,
 
 Gustaf
 
 -- 
 Gustaf Granath (PhD)
 Post doc
 McMaster University
 School of Geography  Earth Sciences
 
 ___
 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] Grid Search in RcppParallel

[Romain Francois]

Envoyé de mon iPhone

 Le 5 oct. 2014 à 07:51, Jeffrey Wong jeff.ct.w...@gmail.com a écrit :
 
 I am trying to use RcppParallel to do a fast grid search.  The idea is to 
 construct a matrix using R's expand.grid, then for each row of that matrix, 
 x, call f(x).  For simplicity the function f will always return a double.  
 Since Rcpp can call an R function I was hoping RcppParallel would allow me to 
 use a parallelFor to process the rows of the grid quickly.  However, it keeps 
 crashing R, and I am wondering if this is because an R function cannot be 
 passed to RcppParallel?

You definitely cannot call an R function concurrently. 

 require(Rcpp)
 require(RcppParallel)
 
 grid = as.matrix(expand.grid(a = 1:5, b = 1:5))
 
 foo = function(pars) {pars[1]^2 + pars[2]^2}
 
 RcppParallelGridSearch(grid, foo)
 
 in .cpp file
 
 #include Rcpp.h
 using namespace Rcpp;
 
 // [[Rcpp::depends(RcppParallel)]]
 #include RcppParallel.h
 using namespace RcppParallel;
 
 struct GridSearch : public Worker
 {
// source matrix
const RMatrixdouble grid;
const Function f;

// destination vector
RVectordouble output;

// initialize with source and destination
GridSearch(const NumericMatrix grid, const Function f, NumericVector 
 output) 
   : grid(grid), f(f), output(output) {}

// take the square root of the range of elements requested
void operator()(std::size_t begin, std::size_t end) {
  
   for (std::size_t i = begin; i  end; i++) {
 RMatrixdouble::Row parameters = grid.row(i);
 output[i] = asdouble(f(parameters));
   }
}
 };
 
 // [[Rcpp::export]]
 NumericVector RcppParallelGridSearch(NumericMatrix grid, Function f) {
   
   // allocate the output matrix
   NumericVector output(grid.nrow());
   
   // SquareRoot functor (pass input and output matrixes)
   GridSearch gridSearch(grid, f, output);
   
   // call parallelFor to do the work
   parallelFor(0, grid.nrow(), gridSearch);
   
   // return the output matrix
   return output;
 }
 
 -- 
 Jeffrey Wong
 My portfolio: http://jeffreycwong.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
___
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] statement about rcpp11 ?

[Romain Francois]

If you want to have a private conversation with Dirk, just email him directly: 
e...@debian.org

Now since this is all in the open, let me participate to this. 

Le 29 sept. 2014 à 22:42, Jonathon Love j...@thon.cc a écrit :

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 hey dirk,
 
 i was wondering if you could let us know your thoughts about Rcpp11.
 
 i've found it a little bit confusing, because at first i thought people
 were just talking about Rcpp (which happens to be at version 0.11).

I also found it confusing that Rcpp's version became 0.11.*
I guess we had it coming after 0.10.* since apparently for some reason it is 
trapped in the 0.* land forever

 then
 i thought it was a newer version of Rcpp, but of course it isn't. then
 i thought it was a version of Rcpp for use with C++11
 (because presumably Rcpp doesn't support C++11... but of course it does).

Yes you can use C++11 with Rcpp, and for that matter you can even use C++11 
without Rcpp. You can do arcane .Call stuff on the outside and have C++11 code 
inside. 

Now Rcpp11 is a complete redesign, focusing on C++11, it means that it actively 
uses C++11, as opposed to let you use it. 

It has also allowed us to step back from mistakes that were made along the way 
when developing Rcpp such as (this is just one example) complexity of too many 
undocumented constructors for *Vector classes. Doing this is impossible with 
Rcpp which has to carry the weight of dependency. 

 so the name alone appears to have been chosen to maximise confusion

Not at all. Rcpp11 stands for R and C++11. 

From my point of view, the confusion comes from the versioning of Rcpp. 

Perhaps Rcpp will hit version 0.14.* when I start working on Rcpp14 soon. How 
convenient would that be. 

 but
 i was wondering what you thought about it technically. do you see it
 replacing ol' Rcpp, and new projects should make an effort to use it
 instead? do you see Rcpp being retired as a result? what is the future
 of repp?

They will coexist, are maintained by two different persons who have different 
goals. And that's fine. 
 
Right now CRAN makes it difficult to depend on Rcpp11, but we have implemented 
a workaround, so the next version of Rcpp11 (to be released when the next R is 
released) will be CRAN proof. 

Just use whatever version is best for your needs. I'm spending a great deal of 
energy and time (although perhaps not lately) on developing Rcpp11, but I still 
use Rcpp for projects for which it makes sense, e.g. dplyr uses Rcpp. 

 perhaps these might make good FAQ entries.
 
 with thanks
 
 jonathon

___
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] Pass an Rcpp module object to a method belonging to another module from R?

[Romain Francois]

This is once again something with which the RCPP_EXPOSED_CLASS macro can help 
with. Try adding 

RCPP_EXPOSED_CLASS(A)

before you declare class A and simply use this signature for the method. 

void DoSomethingWithInstanceOfA(const A ) 

Also, you can have both of these classes in the same module you know; 

RCPP_MODULE(LemonCurry)
{
using namespace Rcpp;

class_A( A )
.constructor();

class_B( B )
.constructor()
.method(DoSomethingWithInstanceOfA, 
B::DoSomethingWithInstanceOfA);
}

Romain. 

PS: Having to resort to that sort of macros is one of the reason that made me 
remove modules from Rcpp11, which will be replaced by something that will be 
nicer to use later. 

Le 10 sept. 2014 à 02:56, Grant Brown grant.brow...@gmail.com a écrit :

 Hi folks, 
 
 I'm building several Rcpp modules which specify parts of a complicated 
 statistical model, and want to pass them to a main module for use. Is there 
 an easy way to do this? 
 
 Below is a simplified example, with question marks where I'm not sure what to 
 do. I've tried accepting a pointer to A, playing with using XPtrs, and a 
 bunch of things which made far less sense, but so far no luck. 
 
 Any suggestions or links to sections of the docs I should revisit would be 
 appreciated. 
 
 Thanks,
 -Grant
 
 
 ## file: A.cpp
 
 class A
 {
   public:
   A();
   ~A();  
 };
 
 class B
 {
   public:
   B();
   void DoSomethingWithInstanceOfA(???);
   ~B();
 };
 
 A::A()
 {
   // Do stuff
 }
 
 B::B()
 {
   // Do stuff
 }
 
 B::DoSomethingWithInstanceOfA(???)
 {
   // Do stuff
 }
 
 RCPP_MODULE(mod_A)
 {
   using namespace Rcpp;
   class_A( A )
   .constructor();
 }
 
 RCPP_MODULE(mod_B)
 {
   using namespace Rcpp;
   class_B( B )
   .constructor()
   .method(DoSomethingWithInstanceOfA, B::DoSomethingWithInstanceOfA);
 }
 
 
 ### End pseduo c++ code
 
 
 ___
 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] Pass an Rcpp module object to a method belonging to another module from R?

[Romain Francois]

Le 10 sept. 2014 à 14:22, Gregory Jefferis jeffe...@mrc-lmb.cam.ac.uk a écrit 
:

 
 
 Gregory Jefferis
 
 On 10 Sep 2014, at 10:39, Romain Francois rom...@r-enthusiasts.com wrote:
 
 RCPP_EXPOSED_CLASS(A)
 
 before you declare class A and simply use this signature for the method. 
 
 void DoSomethingWithInstanceOfA(const A )
 
 
 I used this approach happily in the nabor package (on github) but the only 
 caveat is that from R you need to call with something like:
 
 A$method(B$.CppObject)
 
 You can get some interesting crashes if you pass the R reference class (i.e. 
 B) directly as the argument. I guess it might be better to have a derived R 
 class that looks after extracting the .CppObject field. 
 
 Best,
 
 Greg.

That looks like a bug. Please submit it here: 
https://github.com/RcppCore/Rcpp/issues

___
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] RcppModules with templated class

[Romain Francois]

Le 1 sept. 2014 à 11:48, Dr Gregory Jefferis jeffe...@mrc-lmb.cam.ac.uk a 
écrit :

 Hello,
 
 I have a more or less complete Rcpp(Eigen) dependent package that exposes a 
 pair of C++ classes to R using RcppModules;the C++ classes (which implement k 
 nearest neighbour search trees) differ only in their scalar storage type 
 (float vs double) and are called WKNND and WKNNF. For future 
 flexibility/maintenance I would have like to convert the C++ classes to 
 templated code. Is it possible to use RcppModules to expose template classes? 
 I know that Rcpp in general can be used with template classes, but the 
 RcppModules manual does not seem to mention this.
 
 I have tried to implement this by simple translation of my existing code to a 
 single WKNN class and then defining types for  WKNND and WKNNF (i.e. double 
 and float). However this falls over with errors/notes indicating that the 
 automatic wrap/conversion of Eigen types is failing to pick up the typedef. 
 Error:
 
 In file included from WKNND.cpp:1:
 In file included from 
 /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include/Rcpp.h:27:
 In file included from 
 /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include/RcppCommon.h:169:
 In file included from 
 /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include/Rcpp/as.h:25:
 /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include/Rcpp/internal/Exporter.h:31:28:
  error: no matching constructor for initialization of 'WKNNdouble'
Exporter( SEXP x ) : t(x){}
 ^ ~
 and notes like:
 
 ./WKNN.h:14:8: note: candidate constructor (the implicit copy constructor) 
 not viable: cannot convert argument of incomplete type 'SEXP' (aka 'SEXPREC 
 *') to 'const WKNNdouble'
 struct WKNN {
   ^
 ./WKNN.h:16:3: note: candidate constructor not viable: cannot convert 
 argument of incomplete type 'SEXP' (aka 'SEXPREC *') to 'const 
 Eigen::MapEigen::Matrixdouble, Dynamic, Dynamic '
  WKNN(const Eigen::MapEigen::MatrixT, Dynamic, Dynamic  data, bool 
 buildtree=true);
  ^
 
 So is there a way round this? Do I have to write an explicit wrap function? 
 Do I have to give up on using RcppModules altogether? Any advice or pointers 
 to a package already doing this would be much appreciated. And of course big 
 thanks to Dirk, Romain and Douglas et al for these great packages.
 
 Best wishes,
 
 Greg.
 
 PS Code on this branch:
 
 https://github.com/jefferis/nabor/tree/feature/template-WKNN
 
 with these 2 commits making the changes:
 
 https://github.com/jefferis/nabor/commit/fa85ddae5187f1e93801d7ec36d1d78923384cc6
 https://github.com/jefferis/nabor/commit/9ff93e63023b2f6d9c7ddad54fb7d1f503685b86


Hi, 

This looks related to what RCPP_EXPOSED_CLASS does, perhaps because your class 
comes from a template, you could try RCPP_EXPOSED_CLASS_NODECL instead. The 
only difference is that it does not add the class forward declaration, so you'd 
have to have it after you have defined or declared your class. 

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] (Very) rare segfault

[Romain Francois]

Le 20 août 2014 à 20:57, Gregor Kastner gregor.kast...@wu.ac.at a écrit :

 JJ Yes, RNGScope isn't safe by itself. You can use it via attributes (and we
 JJ make sure to use it correctly) or you could use this pattern e.g. if you
 JJ are planning to return a NumericVector:
 JJ 
 JJ NumericVector vec(20);   // or whatever size, the important thing is
 JJ allocating the return SEXP before RNGScope
 JJ 
 JJ RNGScope rngScope;
 JJ 
 JJ // do your thing
 JJ 
 JJ 
 JJ return vec;

JJ, care to explain this ? I don't follow. 

 OK thanks. That's definitely worth knowing. Might be a cause for trouble for
 others too, especially since misuse (i.e. other ordering) doesn't seem to show
 any effects in many cases.
 
 DE RNGScope is not for for seed setting, it is for RNG 'state sanity'. See
 DE Section 6.3 of 'Writing R Extensions' -- worst case you can just call
 DE GetRNGstate() and PutRNGstate() by hand.  Though we never had to
 DE recommend that yet.
 
 Yep, sorry for the misuse of language. And I do understand going back to
 GetRNGstate() and PutRNGstate() is a bit old school; but I can definitely
 confirm that it seems to be safer than resorting do the
 constructor/destuctor magic.

Compiler/Destructor is not magic. It is determinism. 

That's like feature #1 of C++. 

And BTW it is definitely safer than any manual handling.  

___
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

[Romain Francois]

Le 21 août 2014 à 11:47, Gregor Kastner gregor.kast...@wu.ac.at a écrit :

 On Thu, 21 Aug 2014 11:34:23 +0200
 Romain Francois rom...@r-enthusiasts.com wrote:
 
 GK Yep, sorry for the misuse of language. And I do understand going back to
 GK GetRNGstate() and PutRNGstate() is a bit old school; but I can definitely
 GK confirm that it seems to be safer than resorting do the
 GK constructor/destuctor magic.
 
 Compiler/Destructor is not magic. It is determinism. 
 
 That's like feature #1 of C++. 
 
 agreed: s/magic/automagic/g
 
 And BTW it is definitely safer than any manual handling.  
 
 I cannot say that in the current case, as relying on the destructor does seem
 to create problems (in rare cases, making it even worse!) if objects which
 are to be returned are instantiated after the RNGScope object. Conditional on
 the fact the I understood JJ correctly, that is.

Then it's a bug in how constructor or destructor is implemented in this class, 
probably with the counter. 

Or something invalidates the very assumptions of C++ here. Perhaps raw R api is 
called and the destructor is not called because of some long jump or something. 

Without a repex anyway, it is hard to diagnose what's happening. 

You're probably onto somthing, but going directly to the destructor are not 
safe, I'll just use C function calls is a dangerous route, soon you'll start 
using SEXP as you won't trust ctors/dtors of Rcpp objects do the right thing.

 Manual handling works perfectly.
 
 Best,
 /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

Re: [Rcpp-devel] (Very) rare segfault

[Romain Francois]

That makes sense. No real reason not to use attributes anyway :) 

Le 21 août 2014 à 15:54, JJ Allaire j...@rstudio.com a écrit :

 Yes, the link posted by Matteo is what provoked us to make the change in Rcpp 
 Attributes to dance around the constructor/destructor issues. 
 
 Net: If you are using attributes then this isn't a concern, if you are not 
 then you need the return value SEXP on the stack prior to RNGScope.
 
 On Thursday, August 21, 2014, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Ah interesting. PutRNGstate does indeed allocate so might trigger GC. 
 https://github.com/wch/r-source/blob/fbf5cdf29d923395b537a9893f46af1aa75e38f3/src/main/RNG.c#L437
 
 That's a whole new Pandora's box right there. 
 
 Le 21 août 2014 à 12:10, Matteo Fasiolo matteo.fasi...@gmail.com a écrit :
 
 Hi Romain and Gregor,
 
 maybe I am misunderstanding everything, but hasn't this problem been 
 explained and solved here:
 
 http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2013-May/005838.html
 
 Best,
 
 Matteo
 
  
 
 
 On Thu, Aug 21, 2014 at 10:58 AM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 
 Le 21 août 2014 à 11:47, Gregor Kastner gregor.kast...@wu.ac.at a écrit :
 
  On Thu, 21 Aug 2014 11:34:23 +0200
  Romain Francois rom...@r-enthusiasts.com wrote:
 
  GK Yep, sorry for the misuse of language. And I do understand going back 
  to
  GK GetRNGstate() and PutRNGstate() is a bit old school; but I can 
  definitely
  GK confirm that it seems to be safer than resorting do the
  GK constructor/destuctor magic.
 
  Compiler/Destructor is not magic. It is determinism.
 
  That's like feature #1 of C++.
 
  agreed: s/magic/automagic/g
 
  And BTW it is definitely safer than any manual handling.
 
  I cannot say that in the current case, as relying on the destructor does 
  seem
  to create problems (in rare cases, making it even worse!) if objects which
  are to be returned are instantiated after the RNGScope object. Conditional 
  on
  the fact the I understood JJ correctly, that is.
 
 Then it's a bug in how constructor or destructor is implemented in this 
 class, probably with the counter.
 
 Or something invalidates the very assumptions of C++ here. Perhaps raw R api 
 is called and the destructor is not called because of some long jump or 
 something.
 
 Without a repex anyway, it is hard to diagnose what's happening.
 
 You're probably onto somthing, but going directly to the destructor are not 
 safe, I'll just use C function calls is a dangerous route, soon you'll 
 start using SEXP as you won't trust ctors/dtors of Rcpp objects do the right 
 thing.
 
  Manual handling works perfectly.
 
  Best,
  /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] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang

[Romain Francois]

This is likely to be a bug in Rcpp, don't go bother clang about it:)
Perhaps you can try to remove the bool cast and run the test suite. If 
everything works, then it either means that there are no tests for the 
particular case or that the overload is useless. 

You probably have to consider what happens with : 

list[a] = false ;
bool a = list[a] ;

i.e. does it work when the overload is removed, etc ...

Also, it will be more useful if the example was not using RInside, as this has 
nothing to do with RInside really. You can easily demonstrate the problem with 
a cppFunction or a sourceCpp without having to go through RInside. 

I'd recommend to go here for bug submission: 
https://github.com/RcppCore/Rcpp/issues

Romain

Le 29 juil. 2014 à 10:36, Christian Authmann 
authm...@mathematik.uni-marburg.de a écrit :

 Hi,
 
 the following testcase exposes a difference in gcc and clang
 
  snip 
 #include Rcpp.h
 #include RInside.h
 
 int main(int argc, char *argv[]) {
   // We need some kind of R environment to create a List.
   RInside R;
 
   Rcpp::List list;
   list[a] = 42;
 
   int a_auto = list[a];
   int a_cast = Rcpp::asint(list[a]);
 
   std::cout  list[\a\]=   a_auto  std::endl;
   std::cout  Rcpp::asint(list[\a\]) =   a_cast  std::endl;
 }
  snip 
 
 Results:
 
 gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
 list[a]= 42
 Rcpp::asint(list[a]) = 42
 
 Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
 list[a]= 1
 Rcpp::asint(list[a]) = 42
 
 
 list[a] returns a Rcpp::internal::generic_name_proxy19, which has the 
 following typecasting operators: (rcpp/vector/proxy.h)
 
  snip 
 template typename T
 operator T() const {
   #if RCPP_DEBUG_LEVEL  0
   SEXP res = get() ;
   RCPP_DEBUG_1( generic_name_proxy::get() = %p , res ) ;
   return ::Rcpp::asT( res ) ;
   #else
   return ::Rcpp::asT( get() ) ;
   #endif
 }
 
 operator bool() const{
return ::Rcpp::asbool(get());
 }
  snip 
 
 A few sprinkled printf's reveal that clang will call the bool typecast, while 
 gcc calls the template as intended.
 
 
 Now that I know, I can easily work around it by using Rcpp::as where needed 
 (and I'm posting here so maybe others can find the information), but maybe it 
 should be fixed. ;)
 
 
 I don't know all the intricacies of the C++ standard. Is this a bug in clang? 
 Or is clang free to use any conversion operator it likes, and Rcpp is at 
 fault for relying on implementation details of gcc?
 
 If the former, I'll create a reduced testcase and file a bug with clang.
 
 If the latter, I noticed that removing the bool typecast altogether will 
 cause clang to correctly return 42. Unless there is a good reason for its 
 existence (say, to suppress logging for bool casts), we could just remove it.
 Grep'ping all the includes suggest that this is the only class with redundant 
 typecast operators.
 
 
 Ciao,
 Christian
 
 -- 
 Christian Authmann
 Philipps-Universität Marburg
 Fachbereich Mathematik und Informatik
 AG Datenbanksysteme
 Hans-Meerwein-Straße
 D-35032 Marburg
 ___
 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

[Romain Francois]

Thanks. Hopefully someone will pick it up or at least create an issue by proxy 
for you. 

Romain

Le 29 juil. 2014 à 12:17, Christian Authmann 
authm...@mathematik.uni-marburg.de a écrit :

 I've removed the bool cast from last week's git, reinstalled the package, ran 
 the test suite with --allTests, recompiled my own codes, everything seems to 
 work.
 
 If the bool cast is missing, the code should just fall back to the templated 
 operator T(), with T=bool. Unless RCPP_DEBUG_LEVEL is enabled, those are 
 identical.
 
 
 RUNIT TEST PROTOCOL -- Tue Jul 29 13:20:29 2014
 ***
 Number of test functions: 439
 Number of errors: 0
 Number of failures: 0
 
 
 Sorry, due to a restrictive firewall on my dev computer, I cannot access 
 github from it. A mail will have to suffice for now.
 
 
 Ciao,
 Christian
 
 On 29.07.2014 10:44, Romain Francois wrote:
 This is likely to be a bug in Rcpp, don't go bother clang about it:)
 Perhaps you can try to remove the bool cast and run the test suite. If 
 everything works, then it either means that there are no tests for the 
 particular case or that the overload is useless.
 
 You probably have to consider what happens with :
 
 list[a] = false ;
 bool a = list[a] ;
 
 i.e. does it work when the overload is removed, etc ...
 
 Also, it will be more useful if the example was not using RInside, as this 
 has nothing to do with RInside really. You can easily demonstrate the 
 problem with a cppFunction or a sourceCpp without having to go through 
 RInside.
 
 I'd recommend to go here for bug submission:
 https://github.com/RcppCore/Rcpp/issues
 
 Romain
 
 Le 29 juil. 2014 à 10:36, Christian Authmann 
 authm...@mathematik.uni-marburg.de a écrit :
 
 Hi,
 
 the following testcase exposes a difference in gcc and clang
 
  snip 
 #include Rcpp.h
 #include RInside.h
 
 int main(int argc, char *argv[]) {
 // We need some kind of R environment to create a List.
 RInside R;
 
 Rcpp::List list;
 list[a] = 42;
 
 int a_auto = list[a];
 int a_cast = Rcpp::asint(list[a]);
 
 std::cout  list[\a\]=   a_auto  std::endl;
 std::cout  Rcpp::asint(list[\a\]) =   a_cast  std::endl;
 }
  snip 
 
 Results:
 
 gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
 list[a]= 42
 Rcpp::asint(list[a]) = 42
 
 Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
 list[a]= 1
 Rcpp::asint(list[a]) = 42
 
 
 list[a] returns a Rcpp::internal::generic_name_proxy19, which has the 
 following typecasting operators: (rcpp/vector/proxy.h)
 
  snip 
 template typename T
 operator T() const {
 #if RCPP_DEBUG_LEVEL  0
 SEXP res = get() ;
 RCPP_DEBUG_1( generic_name_proxy::get() = %p , res ) ;
 return ::Rcpp::asT( res ) ;
 #else
 return ::Rcpp::asT( get() ) ;
 #endif
 }
 
 operator bool() const{
return ::Rcpp::asbool(get());
 }
  snip 
 
 A few sprinkled printf's reveal that clang will call the bool typecast, 
 while gcc calls the template as intended.
 
 
 Now that I know, I can easily work around it by using Rcpp::as where needed 
 (and I'm posting here so maybe others can find the information), but maybe 
 it should be fixed. ;)
 
 
 I don't know all the intricacies of the C++ standard. Is this a bug in 
 clang? Or is clang free to use any conversion operator it likes, and Rcpp 
 is at fault for relying on implementation details of gcc?
 
 If the former, I'll create a reduced testcase and file a bug with clang.
 
 If the latter, I noticed that removing the bool typecast altogether will 
 cause clang to correctly return 42. Unless there is a good reason for its 
 existence (say, to suppress logging for bool casts), we could just remove 
 it.
 Grep'ping all the includes suggest that this is the only class with 
 redundant typecast operators.
 
 
 Ciao,
 Christian
 
 -- 
 Christian Authmann
 Philipps-Universität Marburg
 Fachbereich Mathematik und Informatik
 AG Datenbanksysteme
 Hans-Meerwein-Straße
 D-35032 Marburg
 ___
 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] Faster lookup: Named Rcpp::List or std::map?

[Romain Francois]

Lookup in Rcpp::List is linear on something that is quite cheap (comparing 
pointers, because strings in R are cached). 

Lookup in std::map is logarithmic on whatever it means to compare the keys (so 
in your case comparing strings). 
on top of that, copying the data across is linear in the best case scenario 
(when the data is already sorted) or N log(N) otherwise. See: 
http://www.cplusplus.com/reference/map/map/map/

Best is to try both and see which is best for your case. Don't make this just 
one dimensional and consider things like maintainability of your code, ...

Romain

Le 23 juil. 2014 à 15:30, Asis Hallab asis.hal...@gmail.com a écrit :

 Dear Rcpp-Experts,
 
 trying to optimize my algorithm I face the question wether a lookup by
 a string key like e.g.
 
 myRcppList( my_entry ) is as fast as the lookup in std::maps?
 
 That said, would you recommend converting myRcppList to a std::map
 before searching it?
 
 Thank you for your help in advance!
 Cheers!


___
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] Raise a condition

[Romain Francois]

Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :

 I'd like to raise a condition other than error or warning. Is that possible 
 using the Rcpp api? I assume this can be done via R internals, but I'd prefer 
 not to call error() directly (or is that the recommendation?).
 
 THK

Definitely not. Rf_error should really only be called from C code. If you call 
it from C++, there is a great chance you'll lose determinism as destructors for 
your c++ objects are very likely not to be called. Most of the time, it will 
just mean you'll never release some objects to the garbage collector, but it 
could also get you leaks or other nice stuff depending on what your destructors 
were supposed to do and did not get a chance to do.  

I'm not sure Rcpp has a way to raise an R condition apart from calling stop, 
which usually is good enough. Otherwise, you can borrow from Rcpp11 and adapt 
some code from 
https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h

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] Raise a condition

[Romain Francois]

Le 19 juin 2014 à 00:15, Tim Keitt tke...@utexas.edu a écrit :

 
 On Wed, Jun 18, 2014 at 5:07 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :
 
 
 I'd like to raise a condition other than error or warning. Is that possible 
 using the Rcpp api? I assume this can be done via R internals, but I'd 
 prefer not to call error() directly (or is that the recommendation?).
 
 THK
 
 Definitely not. Rf_error should really only be called from C code. If you 
 call it from C++, there is a great chance you'll lose determinism as 
 destructors for your c++ objects are very likely not to be called. Most of 
 the time, it will just mean you'll never release some objects to the garbage 
 collector, but it could also get you leaks or other nice stuff depending on 
 what your destructors were supposed to do and did not get a chance to do.  
 
 That was my understanding. Just wanted to be sure it was still the case.
  
 
 I'm not sure Rcpp has a way to raise an R condition apart from calling stop, 
 which usually is good enough. Otherwise, you can borrow from Rcpp11 and adapt 
 some code from 
 https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h
 
 Ah. I see. Eval stop in the global env with the condition as the argument. 
 Clever.

It is more of a hack due to lack of proper api from R. 

If you do this, make sure you don't have any c++ object in scope. Essentially 
that means you would evaluate `stop( condition )` in a top level catch block. ___
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] Raise a condition

[Romain Francois]

Le 19 juin 2014 à 00:30, Tim Keitt tke...@utexas.edu a écrit :

 On Wed, Jun 18, 2014 at 5:22 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 19 juin 2014 à 00:15, Tim Keitt tke...@utexas.edu a écrit :
 
 
 
 On Wed, Jun 18, 2014 at 5:07 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :
 
 
 I'd like to raise a condition other than error or warning. Is that possible 
 using the Rcpp api? I assume this can be done via R internals, but I'd 
 prefer not to call error() directly (or is that the recommendation?).
 
 THK
 
 Definitely not. Rf_error should really only be called from C code. If you 
 call it from C++, there is a great chance you'll lose determinism as 
 destructors for your c++ objects are very likely not to be called. Most of 
 the time, it will just mean you'll never release some objects to the garbage 
 collector, but it could also get you leaks or other nice stuff depending on 
 what your destructors were supposed to do and did not get a chance to do.  
 
 That was my understanding. Just wanted to be sure it was still the case.
  
 
 I'm not sure Rcpp has a way to raise an R condition apart from calling stop, 
 which usually is good enough. Otherwise, you can borrow from Rcpp11 and 
 adapt some code from 
 https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h
 
 Ah. I see. Eval stop in the global env with the condition as the argument. 
 Clever.
 
 It is more of a hack due to lack of proper api from R. 
 
 If you do this, make sure you don't have any c++ object in scope. Essentially 
 that means you would evaluate `stop( condition )` in a top level catch block. 
 
 Rcpp objects are I assume ok however.

Depends what you mean by ok. If you mean objects like NumericVector, ... 
their destructor is responsible for calling R_ReleaseObject, i.e. let go of the 
protection that was set by their constructor. If the destructor is not called 
because R error handling does a long jump, you will get objects forever 
protected. 

So things will seemingly work, until you exhaust the memory. 

 I will try signalCondition and see what happens.
 
 THK

___
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] Raise a condition

[Romain Francois]

Le 19 juin 2014 à 01:02, Tim Keitt tke...@utexas.edu a écrit :

 
 
 
 On Wed, Jun 18, 2014 at 5:37 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 19 juin 2014 à 00:30, Tim Keitt tke...@utexas.edu a écrit :
 
 On Wed, Jun 18, 2014 at 5:22 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 19 juin 2014 à 00:15, Tim Keitt tke...@utexas.edu a écrit :
 
 
 
 On Wed, Jun 18, 2014 at 5:07 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Le 18 juin 2014 à 23:54, Tim Keitt tke...@utexas.edu a écrit :
 
 
 I'd like to raise a condition other than error or warning. Is that 
 possible using the Rcpp api? I assume this can be done via R internals, 
 but I'd prefer not to call error() directly (or is that the 
 recommendation?).
 
 THK
 
 Definitely not. Rf_error should really only be called from C code. If you 
 call it from C++, there is a great chance you'll lose determinism as 
 destructors for your c++ objects are very likely not to be called. Most of 
 the time, it will just mean you'll never release some objects to the 
 garbage collector, but it could also get you leaks or other nice stuff 
 depending on what your destructors were supposed to do and did not get a 
 chance to do.  
 
 That was my understanding. Just wanted to be sure it was still the case.
  
 
 I'm not sure Rcpp has a way to raise an R condition apart from calling 
 stop, which usually is good enough. Otherwise, you can borrow from Rcpp11 
 and adapt some code from 
 https://github.com/Rcpp11/Rcpp11/blob/450aade7338c16c34618ad0916003e8ca4fb58a6/inst/include/Rcpp/Condition.h
 
 Ah. I see. Eval stop in the global env with the condition as the 
 argument. Clever.
 
 It is more of a hack due to lack of proper api from R. 
 
 If you do this, make sure you don't have any c++ object in scope. 
 Essentially that means you would evaluate `stop( condition )` in a top level 
 catch block. 
 
 Rcpp objects are I assume ok however.
 
 Depends what you mean by ok. If you mean objects like NumericVector, ... 
 their destructor is responsible for calling R_ReleaseObject, i.e. let go of 
 the protection that was set by their constructor. If the destructor is not 
 called because R error handling does a long jump, you will get objects 
 forever protected. 
 
 So things will seemingly work, until you exhaust the memory. 
 
 I will try signalCondition and see what happens.
 
 THK
 
 
 I can't get signalCondition to do anything.

What exactly did you try ? Did you catch the condition at the R level, with 
withCallingHandlers or something. Just because you don't see something does not 
mean nothing happens. 

 This works although I've not tested it for leaks.

Easy enough to test for forgotten destructors. 

#include Rcpp.h
using namespace Rcpp; 

void raise_condition(const std::string msg,
 const std::string type)
{
  List cond;
  cond[message] = msg;
  cond[call] = R_NilValue;
  cond.attr(class) = CharacterVector::create(type, condition);
  Function stopper(stop);
  stopper(cond);
}

class A {
   public:
   A(){ Rprintf( A::A()\n ) ; }
   ~A(){ Rprintf( A::~A()\n ) ; }
} ;


// [[Rcpp::export]]
void test(){
A a ;
raise_condition( foo, bar) ;  
}

/*** R
test()
*/

which gives me:

 test()
A::A()
Error: foo

So the destructor for A is never called. Not a big deal here, it was not doing 
anything. But might be more problematic elsewhere. 

 void raise_condition(const std::string msg,
  const std::string type)
 {
   List cond;
   cond[message] = msg;
   cond[call] = R_NilValue;
   cond.attr(class) = CharacterVector::create(type, condition);
   Function stopper(stop);
   stopper(cond);
 }
 
 THK
 
 -- 
 http://www.keittlab.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

Re: [Rcpp-devel] Raise a condition

[Romain Francois]

Le 19 juin 2014 à 03:05, Dirk Eddelbuettel e...@debian.org a écrit :

 
 On 18 June 2014 at 19:40, Tim Keitt wrote:
 | 
 | 
 | 
 | On Wed, Jun 18, 2014 at 6:26 PM, Dirk Eddelbuettel e...@debian.org wrote:
 | 
 | 
 | Tim,
 | 
 | Step back for a second and recognise that everything happens via
 | 
 |SEXP .Call(SEXP a, SEXP b, ...)
 | 
 | where R calls your C++ routine asynchronously.
 | 
 | You can do tricks _within the subroutine that is called_ which is
 | essentially
 | what happens via the automatically-added try/catch block we have in C++.
 |  And
 | Rcpp::stop() is just a shortcut for using those.
 | 
 | 
 | Can I throw a condition (meaning an object inheriting class condition) or 
 am
 | I limited to strings? If I throw a condition, will it be raised as such?
 
 See eg Section 2.7 titled Exception Handling in my Springer book on Rcpp.
 This is standard stuff, and we discussed the basics in the 2011 JSS paper.
 
 You can throw anything that is subclassed from std::exception, and catch it
 appropriately.  The default mechanism is to take the exception text and pass
 it to R -- because, once again, passing a string is all we can do.  _Your_
 code could course provide more complex things and keep them, and tickle (by
 error codes) retrieval via other functions.
 
 But again, the interface we are given by R is fixed.  You can only be
 creative within the confines of that interface.

Would be relatively easy to add an overload to stop
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/exceptions.h#L195

so that it handles other things besides strings. 

The confines of the R interface is not the problem here. 


___
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] Error during wrapup

[Romain Francois]

This looks like a protection issue. 

For whomever this makes sense to: From the code that wraps such object, i would 
investigate the call to setAttrib. 

Perhaps we are supposed to get the result of it and protect it. 

So i would tend to use an Armor instead of a Shield. 

Romain

Le 28 mai 2014 à 16:02, John Mous john.mo...@gmail.com a écrit :

 Hmm, unfortunately the GitHub version failed also. The attributes on the 
 failed object are a little different though, here's what they look like:
 
 Browse[1] str(results)
  atomic [1:4] 1 1 2270 0
  - attr(*, )= symbol sim
  - attr(*, value)= promise to  NULL
 
 
 On Tue, May 27, 2014 at 6:10 PM, John Mous john.mo...@gmail.com wrote:
 Hi Kevin,
 
 Thanks. I will give the GitHub version a try -- the error usually manifests 
 only after running for about a day or so, so it may take a while to do that. 
 Unfortunately I am having trouble creating a small reproducible example -- a 
 function with just the assignments as written in my previous e-mail works 
 fine when executed thousands of times in a loop. The full  code is not that 
 long (~165 lines), but is also non-trivial. 
 
 It's odd that something else is causing things to fail with the end result 
 being that only the field *names*, which are hardcoded, and not the values, 
 not coming through properly. Since you said you suspect the problem may be 
 fixed, can you give me a hint of what you think it may be related to? This 
 might help me isolate the piece of offending code.
 
 
 
 On Tue, May 27, 2014 at 5:46 PM, Kevin Ushey kevinus...@gmail.com wrote:
 Hi John,
 
 I think we may have tackled this in some of the latest fixes with the
 version of Rcpp on GitHub. Can you try installing that version and
 trying again? Ie, try
 
 install.packages(devtools); devtools::install_github(RcppCore/Rcpp)
 
 then try running your code again.
 
 Alternatively, please supply a small reproducible example that we can
 try to run ourselves. You may be able to tease this error out
 reproducibly if you run it with gctorture(TRUE) on.
 
 Thanks,
 Kevin
 
 On Tue, May 27, 2014 at 2:42 PM, John Mous john.mo...@gmail.com wrote:
  Hello,
 
  I am passing back a very simple std::mapstd::string, int from Rcpp as
  follows:
 
  std::mapstd::string, int result;
  result[X1] = X1;
  result[X2] = X2;
  result[X3] = X3;
  result[X4] = X4;
  return wrap(result);
 
  The keys are hardcoded as shown, and the values X1-X4 are ints. Almost
  always everything works fine, however, very intermittently, a vector is
  returned on the R side _without_ named fields. For example:
 
  Browse[1] results
  [1]   1   2 863   0
  Error during wrapup: 'getCharCE' must be called on a CHARSXP
  Browse[1] str(results)
   atomic [1:4] 1 2 863 0
   - attr(*, )= symbol X1
   - attr(*, )= language `[[-`(`*tmp*`, sim, value = 1L)
 
  results[[X1]] works, but results[[X1]] does not, and X2-X4 can be
  retrieved only by index. However, again, most runs are successful:
 
  Browse[1] results
   X1  X2  X3  X4
 11 32540
  Browse[1] str(results)
   Named int [1:4] 1 1 3254 0
   - attr(*, names)= chr [1:4] X1 X2 X3 X4
 
 
  I am using R 3.1.0 and Rcpp 0.11.1. Does the message Error during wrapup:
  'getCharCE' must be called on a CHARSXP within this context hint anything
  to anyone familiar with Rcpp's internals? I realize it's almost impossible
  to diagnose with the given information -- is there a way to get Rcpp to
  display more debugging information?
 
  Thank you.
 
  ___
  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] Error during wrapup

[Romain Francois]

(now with some links):

Le 28 mai 2014 à 16:31, John Mous john.mo...@gmail.com a écrit :

 The object really is just built as part of the return statement. i.e. the 
 lines from my prior e-mail exist as-is in the full code,

Sure. What happens is that Rcpp::export generates something that calls wrap( 
std::mapstd::string,int ). 

 there's just more that actually builds the variables X1-X4 beforehand.

It should not be relevant. 

 So I'm not sure where to debug from the client side. I'm a C/C++ developer, 
 but have no experience with Rcpp internals or the general interface between R 
 and C. I can insert some debug statements on the Rcpp side if you can guide 
 me to where wrap is defined. 

well wrap is defined here: 
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28

It then performs a series of dispatch, that eventually lead to something that 
handles std::mapstd::string,int: 
https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255

template typename InputIterator, typename T
inline SEXP range_wrap_dispatch___impl__cast( InputIterator first, 
InputIterator last, ::Rcpp::traits::false_type ){
size_t size = std::distance( first, last ) ;
const int RTYPE = ::Rcpp::traits::r_sexptype_traitstypename 
T::second_type::rtype ;
ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
CTYPE* start = r_vector_startRTYPE(x) ;
size_t i =0;
std::string buf ;
for( ; isize; i++, ++first){
start[i] = (*first).second ;
buf = (*first).first ;
SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ;
}
::Rf_setAttrib( x, R_NamesSymbol, names ) ;
return wrap_extra_stepsT( x ) ;
}

what I suspect to be the problem is this line:

 ::Rf_setAttrib( x, R_NamesSymbol, names ) ;


 What Romain says makes sense to me, despite my lack of expertise in this 
 area.. the really intermittent nature of the problem and the fact that I 
 can't recreate it in a small / fast running example suggests that perhaps 
 this manifests when R happens to garbage collect at an unfortunate time (if I 
 understood correctly). Thanks again.

Something like that. as hadley hinted, please try this under gc torture, or 
preferably through a debugger. 

 On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel e...@debian.org wrote:
 
 On 28 May 2014 at 10:02, John Mous wrote:
 | Hmm, unfortunately the GitHub version failed also.
 
 Darn.
 
 | The attributes on the failed
 | object are a little different though, here's what they look like:
 |
 | Browse[1] str(results)
 |  atomic [1:4] 1 1 2270 0
 |  - attr(*, )= symbol sim
 |  - attr(*, value)= promise to  NULL
 
 I am not sure what we can do without a reproducible example. :-/
 The code just got a review / refreshment over the last few months.
 
 You best bet may the slow and tedious insertion of debug statements to see
 when / if the object changes.
 
 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

___
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] Error during wrapup

[Romain Francois]

Le 29 mai 2014 à 00:35, John Mous john.mo...@gmail.com a écrit :

 No luck with gctorture on yet, but I haven't run it for very long. It slowed 
 things down to a complete crawl, but maybe in the long run it can recreate 
 the problem faster than running the original code (about 12 hours, the 
 previous estimate of a day was too high), so this may still be worthwhile. 
 
 On a whim I did try changing the two instances of Shield to Armor this 
 morning (I was able to locate the code in wrap.h by digging around before I 
 saw your e-mail) and ran the original full code without gctorture on, and the 
 problem still persists. 

Would not be enough, you'd also have to do: 

x = ::Rf_setAttrib( x, R_NamesSymbol, names ) ;

so that the result of setAttrib gets protected even if it is a new SEXP, which 
AFAIU can happen with setAttrib. 

But I'm not sure this is the problem. 

Romain

 
 On Wed, May 28, 2014 at 3:44 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 (now with some links):
 
 Le 28 mai 2014 à 16:31, John Mous john.mo...@gmail.com a écrit :
 
 The object really is just built as part of the return statement. i.e. the 
 lines from my prior e-mail exist as-is in the full code,
 
 Sure. What happens is that Rcpp::export generates something that calls wrap( 
 std::mapstd::string,int ). 
 
 there's just more that actually builds the variables X1-X4 beforehand.
 
 It should not be relevant. 
 
 So I'm not sure where to debug from the client side. I'm a C/C++ developer, 
 but have no experience with Rcpp internals or the general interface between 
 R and C. I can insert some debug statements on the Rcpp side if you can 
 guide me to where wrap is defined. 
 
 well wrap is defined here: 
 https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap_end.h#L28
 
 It then performs a series of dispatch, that eventually lead to something that 
 handles std::mapstd::string,int: 
 https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/internal/wrap.h#L255
 
 
 template typename InputIterator, typename T
 
 inline SEXP range_wrap_dispatch___impl__cast( InputIterator first, 
 InputIterator last, ::Rcpp::traits::false_type ){
 
   size_t size = std::distance( first, last ) ;
 
   const int RTYPE = ::Rcpp::traits::r_sexptype_traitstypename 
 T::second_type::rtype ;
 
   ShieldSEXP x( Rf_allocVector( RTYPE, size ) );
 
   ShieldSEXP names( Rf_allocVector( STRSXP, size ) ) ;
 
   typedef typename ::Rcpp::traits::storage_typeRTYPE::type CTYPE ;
 
   CTYPE* start = r_vector_startRTYPE(x) ;
 
   size_t i =0;
 
   std::string buf ;
   for( ; isize; i++, ++first){
 
   start[i] = (*first).second ;
 
   buf = (*first).first ;
 
   SET_STRING_ELT( names, i, Rf_mkChar(buf.c_str()) ) ;
 
   }
   ::Rf_setAttrib( x, R_NamesSymbol, names ) ;
 
   return wrap_extra_stepsT( x ) ;
 
 }
 
 what I suspect to be the problem is this line:
 
  ::Rf_setAttrib( x, R_NamesSymbol, names ) ;
 
 
 What Romain says makes sense to me, despite my lack of expertise in this 
 area.. the really intermittent nature of the problem and the fact that I 
 can't recreate it in a small / fast running example suggests that perhaps 
 this manifests when R happens to garbage collect at an unfortunate time (if 
 I understood correctly). Thanks again.
 
 Something like that. as hadley hinted, please try this under gc torture, or 
 preferably through a debugger. 
 
 On Wed, May 28, 2014 at 10:12 AM, Dirk Eddelbuettel e...@debian.org wrote:
 
 On 28 May 2014 at 10:02, John Mous wrote:
 | Hmm, unfortunately the GitHub version failed also.
 
 Darn.
 
 | The attributes on the failed
 | object are a little different though, here's what they look like:
 |
 | Browse[1] str(results)
 |  atomic [1:4] 1 1 2270 0
 |  - attr(*, )= symbol sim
 |  - attr(*, value)= promise to  NULL
 
 I am not sure what we can do without a reproducible example. :-/
 The code just got a review / refreshment over the last few months.
 
 You best bet may the slow and tedious insertion of debug statements to see
 when / if the object changes.
 
 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
 
 

___
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] Questions on extending Rcpp wrap and as with templates

[Romain Francois]

Le 6 mai 2014 à 08:45, Florian Burkart florian.burk...@gmail.com a écrit :

 Hi everyone (and Dirk),
 
 Second attempt on corrected email list.
 
 I have been trying to extend Rcpp with my own wrap and as templates.
 
 Two issues:
 
 1) I need to explicitly call wrap. Is that expected?
 
 So for example I wrote this specialization:

This is not a specialization, just another overload. You need to write a 
specialization, as in: 

namespace Rcpp{
template SEXP wrapstd::vector TimedOptDouble   
(std::vectorTimedOptDouble const entries) { … }
}

 template SEXP Rcpp::wrap(std::vectorTimedOptDouble const entries) {
   std::vectordouble sec_times;
   std::vectordouble doubles;
   for(auto const entry : entries)
   {
   sec_times.push_back(entry.GetTime().Seconds());
   TimedOptDouble::OptDouble opt_double(entry.GetOptDouble());
   if(opt_double)
   doubles.push_back(*opt_double);
   else
   doubles.push_back(R_NaReal);
   }
   return List::create(
   Named( Time ) = sec_times,
   Named( Value ) = doubles);
 }
 
 First of all, this returns what I believe to be a Rcpp::List object, which 
 seems to be converted implicitly to a SEXP. This is the typical behaviour I 
 know.
 
 Unfortunately, when making use of this template, it doesn't work implicitly, 
 but I need to explicitly call it.
 
 So for example
 
 SEXP GetSunPositions(SEXP a) {
   std::vectorTimedOptDouble sun_positions;
   ...
   return wrap(sun_positions);
 }
 
 works, where as
 
 return sun_positions;
 
 as last line doesn't. Am I doing something wrong here? I did do the 
 declaration before including Rcpp.h.

This should work if you return a std::vector TimedOptDouble  from your 
function, as in: 

std::vector TimedOptDouble  GetSunPositions(SEXP a) { … }

 2) How to make as work for own types in containers
 
 The other way around, one can return a std::vectordouble implicitly, but 
 how do I return std::vectorMyType? I tried to define
 
   template MyType as(SEXP);
 
 But that didn't help, e.g. I had to write my own
 
   template std::vectorMyType as(SEXP);

This is the easiest way. A more general way would need you to express how to 
handle containers of MyType, but that requires defining some traits classes etc 
… not sure it is worth the effort. 

But again, you’d need to actually write a specialization: template 
std::vectorMyType as std::vectorMyType  (SEXP);

Romain


 Thanks for 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 to create list of list without known structure

[Romain Francois]

Le 6 mai 2014 à 09:35, Florian Burkart florian.burk...@gmail.com a écrit :

 Hi,
 
 I have been creating lists of lists with 
 
 return Rcpp::List::create(Rcpp::Named(vec) = someVector,
   Rcpp::Named(lst) = someList,
   Rcpp::Named(vec2) = someOtherVector);
 
 or to follow Romain:
 
 using namespace Rcpp ;
 return List::create( 
_[vec]  = someVector, 
_[lst]  = someList, 
_[vec2] = someOtherVector
  ) ;
 
 But how do I convert the following into a list of lists?
 
 std::vectorstd::string m_column_headers;
 std::vectorstd::vectorOptDouble  m_vectors_of_values;

You probably just need to know about .names() =, i.e. something like this 
should do: 

List values = wrap(m_vectors_of_values) ;
values.names()  = m_column_headers ;

FWIW, in Rcpp11, you could use structure, e.g. :

List values = structure( m_vectors_of_values, _[names] = m_column_headers ) ;

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] g++ flags

[Romain Francois]

That looks alright to me. But apparently dirk has another way to do it that 
does not depend on R 3.1.0, whatever works.  

Romain

Le 30 avr. 2014 à 16:15, JJ Allaire jj.alla...@gmail.com a écrit :

 Romain,
 
 I think this PR addresses the issue:
 
 https://github.com/RcppCore/Rcpp/pull/143
 
 I've tested and it seems to work as intended. Is this fix you were conceiving 
 of or is there something more we should be doing?
 
 J.J.
 
 
 On Wed, Apr 30, 2014 at 9:19 AM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 The plugin as implemented now is not portable. The easiest way to make it 
 portable would be to define the USE_CXX1X environment variable, which R 
 knows how to interpret.
 
 This way R would do what makes sense, i.e. use -std=c++0x on windows (for 
 which rtools is limited to gcc 4.6.3 now) and -std=c++11 when it makes sense.
 
 Romain
 
 Le 30 avr. 2014 à 15:10, Darren Cook dar...@dcook.org a écrit :
 
  The problem seems to be that Rcpp uses -std=c++11; however, g++ 4.6.3,
  which is what comes with the latest version of Rtools on Windows, uses
  -std=c++0x or -std=gnu++0x ...
 
  In g++ 4.8.1 those two are deprecated in favour of -std=c++11 and
  -std=gnu++11 respectively; however they are still available.
 
  Darren
 
 ___
 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] Parallel random numbers using Rcpp and OpenMP

[Romain Francois]

Hi, 

If you can assume c++11, you might bot need openmp, as you can just use 
standard support for threads, etc ... 

Although the compiler suite used on windows (if you care about that) does not 
support c++11 threads. This might be available later. 

Romain


Le 28 avr. 2014 à 12:51, Matteo Fasiolo matteo.fasi...@gmail.com a écrit :

 Hi all,
 
  many thanks for your detailed replies, I see that there are many options out 
 there.
 
 As a first step I think I will try out the C++11 option that Matt suggested, 
 as it seems
 relatively simple. In particular I might do something like:
 
 #pragma omp parallel
 {
 std::mt19937_64 engine( static_castuint64_t(seeds[omp_get_thread_num()] 
 ) );
 std::uniform_real_distributiondouble zeroToOne(0.0, 1.0);
 
 #pragma omp for
 for (int i = 0; i  1000; i++) {
 double a = zeroToOne(engine);
 }
 }
 
 were seeds is a NumericVector coming from R. That's probably not ideal, but 
 it might
 give reasonable and reproducible results.
 
 Thanks,
 
 Matteo
 
 
 
 On Mon, Apr 28, 2014 at 9:39 AM, Matt D. mat...@gmail.com wrote:
 On 4/28/2014 01:30, Matteo Fasiolo wrote:
 [...]
 
 
 As I understand, doing things such as:
 
 NumericMatrix out(n, d);
 #pragma omp for schedule(static)
 for(int kk = 0; kk  d; kk++) out( _, kk) = rnorm(n);
 
 is not going to work, because rnorm() is not thread safe
 (in fact this code crashed R). On the other hand R level parallelism
 using clusterApply, mclapply etc appears to be too slow to be of any
 use for this purpose.
 
 Is anybody aware of any package providing a parallel C++ rng which my
 package might link to?
 Your first choice can be to go with the C++ Standard Library -- header 
 random -- (importantly) using one object per thread:
 http://stackoverflow.com/questions/8813592/c11-thread-safety-of-random-number-generators
 
 See:
 http://en.cppreference.com/w/cpp/numeric/random
 http://isocpp.org/blog/2013/03/n3551-random-number-generation
 
 Since you're using OpenMP, you can get the distinct thread ID by using the 
 `omp_get_thread_num` function:
 http://stackoverflow.com/questions/15918758/how-to-make-each-thread-use-its-own-rng-in-c11
 
 Note that if you're doing large scale parallel statistics (say, Monte Carlo) 
 you may also want a PRNG with statistical properties which don't deteriorate 
 (e.g., no spurious correlation, let alone overlapping) for very large 
 samples; preferably, also one that doesn't maintain any kind of global state 
 (so-called stateless) is going to be easier to use, too (nothing to 
 synchronize/lock across threads).
 
 A relatively recent work that's particularly relevant is Random123:
 https://www.deshawresearch.com/resources_random123.html
 http://www.thesalmons.org/john/random123/
 
 MIT-licensed C++ version is available here:
 http://www.sitmo.com/article/parallel-random-number-generator-in-c/
 
 With a simple example:
 http://www.sitmo.com/article/multi-threaded-random-number-generation-in-c11/
 
 // The author is currently working on getting it into Boost.Random; 
 discussion: 
 http://www.wilmott.com/messageview.cfm?catid=44threadid=95882STARTPAGE=2#710955
 
 HTH,
 
 Best,
 
 Matt
 
 
 ___
 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

[Rcpp-devel] Rcpp11 3.1.0 is on CRAN

[Romain Francois]

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

Re: [Rcpp-devel] Generic R and C++ discussion

[Romain Francois]

Le 8 avr. 2014 à 13:28, stat quant mail.statqu...@gmail.com a écrit :
 Hi, 
 Will that be ok to ask Rcpp questions to on this list too? 
 

Definitely. Anything R and C++ related. 

 On 8 Apr 2014 09:56, Romain François rom...@r-enthusiasts.com wrote:
 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

___
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 syntactic sugar equivalent for R's optimize() function

[Romain Francois]

Le 28 févr. 2014 à 11:52, Gregor Kastner gregor.kast...@wu.ac.at a écrit :

 Hi Hideyoshi,
 
 Is there a way I can just call that function in Rcpp rather than having to
 install new libraries or create my own? (I presume that there is probably a
 “C_do_fmin.c” file somewhere that I can use?)
 
 This questions has been discussed in this list about a month ago:
 
 http://r.789695.n4.nabble.com/Linking-to-native-routines-in-other-packages-tt4683969.html#none

As Dirk said, this is not the same thing. The level of complexity of calling an 
internal function of the stats package is quite high. 

I’d suggest :
- reimplement clean c++ code as Dirk says
- call the R function optimize form C++. Chances are the overhead of doing that 
is minimal and anecdotic compared to calling the objective function. 
- use something else as Dale says. 

 I am now using the approach that Romain suggested in this thread. Be sure to
 include
 
 PKG_CPPFLAGS+=-I../inst/include/

As it has been reported to me by Brian Ripley, += is a gnu-ism so it is not 
portable. 
Also, you should not have the last `/` So: 

PKG_CPPFLAGS = -I../inst/include


 in the Makevars and Makevars.win files. AFAIK know this mechanism is not
 automated (yet), see
 http://r.789695.n4.nabble.com/LinkingTo-self-tt4684613.html
 
 Best,
 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

Re: [Rcpp-devel] Default empty values for vector and matrices

[Romain Francois]

Le 17 févr. 2014 à 12:17, Alessandro Mammana mamm...@molgen.mpg.de a écrit :

 Dear all,
 I am trying to write an Rcpp function that accepts optionally a
 vector, but I cannot figure out what default value I should give to
 it.
 
 First I tried the following:
 
 // [[Rcpp::export]]
 int nilVec(NumericVector v = R_NilValue){
int sum = 0;
for (int i = 0; i  v.length(); ++i){
sum += v[i];
}
return sum;
 }
 
 but when trying:
 nilVec()
 I get the error Not compatible with REALSXP, which is maybe not very
 consistent with the fact that in R you can do as.numeric(NULL) and it
 gives you a vector of length 0.

R’s behavior is incoherent. NULL is not a numeric vector. 


 Then I tried:
 
 // [[Rcpp::export]]
 int nilVec(NumericVector v = NumericVector()){
int sum = 0;
for (int i = 0; i  v.length(); ++i){
sum += v[i];
}
return sum;
 }
 
 but it doesn't compile.

That’s the attribute parser not making sense of it. It does compile, but the 
default is not propagated to R. 

 I found the following discussion:
 http://comments.gmane.org/gmane.comp.lang.r.rcpp/5922 where I
 discovered that for whatever reason the following compiles and works:
 
 // [[Rcpp::export]]
 int nilVec(NumericVector v = NumericVector::create(0)){
int sum = 0;
for (int i = 0; i  v.length(); ++i){
sum += v[i];
}
return sum;
 }

Well. It might appear as something that works. It is in fact a bug. 
NumericVector::create(0) is supposed to create a vector of length 1 with the 
value of the first element set to 0. not numeric vector of length zero as it is 
currently the case. bug. 
https://github.com/RcppCore/Rcpp/issues/117


 But the funny thing is that this does not work:
 
 // [[Rcpp::export]]
 int nilMat(NumericMatrix v = NumericMatrix::create(0)){
int sum = 0;
for (int i = 0; i  v.length(); ++i){
sum += v[i];
}
return sum;
 }

Matrix::create is nonsense as it does not create a matrix. check : 

 m - evalCpp( NumericMatrix::create(0) )
 str(m)
 num 0

so creates a vector, not a matrix. Besides, what do you actually expect. What 
dimensions would this matrix have ?


 So how should I do for matrices? I would also be happy with the
 solution of defining somewhere an empty vector  or an empty matrix and
 assigning it as default argument, but the following does not work:

My suggestion would be to handle this on the R side. The attribute parser is 
not a fully capable C++ parser, stick to defaults for only very simple things, 
like int or double or strings. 

For anything else, you’re better of with dealing with the parameter logic on 
the R side. 

 NumericVector empty(0);
 
 // [[Rcpp::export]]
 int nilVec(NumericVector v = empty){
int sum = 0;
for (int i = 0; i  v.length(); ++i){
sum += v[i];
}
return sum;
 }
 
 
 Suggestions? I would be super happy if in the future the special value
 R_NilValue could be converted to an empty vector, it would make things
 very easy and coherent with R's behaviour.
 
 Thx 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] Segfault, is it because of iterators/pointers?

[Romain Francois]

Le 12 févr. 2014 à 13:36, Alessandro Mammana mamm...@molgen.mpg.de a écrit :

 Ah wait, my bad (as always T.T), I found a much simpler explanation:
 
 colset - sample(3e7-nr, 1e7)
 storage.mode(colset)
 [1] integer
 storage.mode(colset-1)
 [1] double
 
 So when I was unwrapping colset I allocated new memory in Rcpp to
 convert from double to integer, which was no longer valid when I went
 out of scope.
 I think it is a bit dangerous that you never know if you are
 allocating memory or just wrapping R objects when parsing arguments in
 Rcpp.
 Is there a way of ensuring that NOTHING gets copied when parsing
 arguments? Can you throw an exception if the type you try to cast to
 is not the one you expect?
 You might imagine that with large datasets this is important.

Silent coercion was added by design. Rcpp does not give you a « strict » mode. 

One thing you can do is something like this: 

#include Rcpp.h
using namespace Rcpp ;

template typename T
class Strict : public T {
public:
  Strict( SEXP x ) {
if( TYPEOF(x) != T::r_type::value )
  stop( not compatible ) ;
T::Storage::set__(x) ;
  }

} ;

// [[Rcpp::export]]
int foo( StrictNumericVector v ){
  return v.size() ;
}

You’d get e.g. 

 foo(rnorm(10))
[1] 10

 foo(1:10)
Error in eval(expr, envir, enclos) : not compatible
Calls: sourceCpp ... source - withVisible - eval - eval - foo - Anonymous
Execution halted



 Sorry for bothering and thanks again,
 Ale
 
 
 On Wed, Feb 12, 2014 at 1:10 PM, Dirk Eddelbuettel e...@debian.org wrote:
 
 On 12 February 2014 at 11:47, Alessandro Mammana wrote:
 | Ok I was able to find the code causing the bug. So it looks like the
 
 Thanks for the added detail.
 
 | pointers you get from an Rcpp::Vector using .begin() become invalid
 | after that the Rcpp::Vector goes out of scope (and this makes sense),
 | what I do not understand is that this Rcpp::Vector was allocated in R
 | and should still be living during the execution of the Rcpp call
 | (that's why I wasn't expecting the pointer to be invalid).
 |
 | This is the exact code (the one above is probably fine):
 | @@ in CPP @@i
 |
 | struct GapMat {
 | int* ptr;
 | int* colset;
 | int nrow;
 | int ncol;
 |
 |
 | inline int* colptr(int col){
 | return ptr + colset[col];
 | }
 |
 | GapMat(){}
 |
 | GapMat(int* _ptr, int* _colset, int _nrow, int _ncol):
 | ptr(_ptr), colset(_colset), nrow(_nrow), ncol(_ncol){}
 | };
 |
 |
 | GapMat getGapMat(Rcpp::List gapmat){
 | IntegerVector vec = gapmat[vec];
 | IntegerVector pos = gapmat[colset];
 | int nrow = gapmat[nrow];
 |
 | return GapMat(vec.begin(), pos.begin(), nrow, pos.length());
 | }
 |
 | // [[Rcpp::export]]
 | IntegerVector colSumsGapMat(Rcpp::List gapmat){
 |
 | GapMat mat = getGapMat(gapmat);
 | IntegerVector res(mat.ncol);
 |
 | for (int i = 0; i  mat.ncol; ++i){
 | for (int j = 0; j  mat.nrow; ++j){
 | res[i] += mat.colptr(i)[j];
 | }
 | }
 |
 | return res;
 | }
 |
 | @@ in R (with gdb debugger as suggested by Dirk) 
 @@i
 | library(Rcpp)
 | sourceCpp(scratchpad.cpp)
 |
 | vec - rnbinom(3e7, mu=0.1, size=1); storage.mode(vec) - integer
 | nr - 80
 |
 | colset - sample(3e7-nr, 1e7)
 | foo - vec[colset] #this is only to trigger some obscure garbage
 | collection mechanisms...
 |
 | for (i in 1:10){
 | colset - sample(3e7-nr, 1e7)
 | gapmat - list(vec=vec, nrow=nr, colset=colset-1)
 | cs - colSumsGapMat(gapmat)
 | print(sum(cs))
 | }
 |
 | [1] 8000
 | [1] 8000
 | [1] 80016890
 | [1] 80008144
 | [1] 80016022
 | [1] 80021609
 |
 | Program received signal SIGSEGV, Segmentation fault.
 | 0x718a5455 in GapMat::colptr (this=0x7fffc120, col=0) at
 | scratchpad.cpp:295
 | 295return ptr + colset[col];
 |
 | @@@
 |
 | Why did it happen? What should I do to make sure that my pointers
 | remain valid? My goal is to convert safely some vectors or matrices
 | that exist in R to some pointers, how can I do that?
 
 Not sure. It looks fine at first instance. But then it's early in the morning
 and I had very little coffee yet...
 
 Maybe the fact that you tickle the gc() via vec[colset] has something to do
 with it, maybe it has not.  Maybe I would try the decomposition of the List
 object inside the colSumsGapMat() function to keep it simpler.  Or if you
 _really_ want an external object to iterate over, memcpy it out.
 
 With really large object, you may be stressing parts of the code that have
 not been stressed the same way.  If it breaks, you do get to keep both 
 pieces.
 
 Dirk
 
 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
 
 
 
 -- 
 Alessandro Mammana, PhD Student
 Max Planck Institute for Molecular Genetics
 Ihnestraße 63-73
 D-14195 Berlin, Germany
 ___
 Rcpp-devel mailing list
 

Re: [Rcpp-devel] calling and R function from rcpp and evaluation

[Romain Francois]

Hi Antonio, 

This is about how R evaluation works. Might not just be what you think it is. 

When you use Rcpp and therefore .Call things are evaluated fairly early, at 
least earlier than what would happen with R, etc … you can reproduce what R 
does by using promises. For example this work in Rcpp11: 

// [[Rcpp::export]]
RawVector rcpp_serialize(Dots dots){
  Function serialize(serialize) ;
  return serialize( dots.promise(0), R_NilValue ) ;
}

Dots has not been implemented in Rcpp, but would not be too hard to port: 
https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Dots.h

But it would also need to fix Rcpp’s handling of recursive promises (i.e. 
promise of a promise of a promise). 



Alternatively, for a solution based on Rcpp, you can look in dplyr. The 
.data_dots function has most of the R-level logic
https://github.com/hadley/dplyr/blob/master/R/manip-df.r

And the C++ logic is mostly in DataDots.h
https://github.com/hadley/dplyr/blob/master/inst/include/tools/DataDots.h

Romain

Le 6 févr. 2014 à 02:07, Antonio Piccolboni anto...@piccolboni.info a écrit :

 Hi,
 I was wondering why I can serialize a call such as in
 
 serialize(call(ripley), NULL) 
 [1] 58 0a 00 00 00 02 00 03 00 02 00 02 03 00 00 00 00 06 00 00 00 01 00 04 
 00 09 00 00 00 06 72 69 70 6c 65 79 00 00 00 fe
 
 but if I try from C++ the call gets evaluated
 
  library(Rcpp)
 
  rcpp.serialize = cppFunction(code=RObject my_serialize(RObject x){Function 
 r_serialize(\serialize\); return r_serialize(x, R_NilValue);})
 
  rcpp.serialize(10)
  [1] 58 0a 00 00 00 02 00 03 00 02 00 02 03 00 00 00 00 0e 00 00 00 01 40 24 
 00 00 00 00 00 00
 # easy things work
 
  rcpp.serialize(call(ripley))
 Error: could not find function ripley
 # wants to evaluate it
 
  unserialize(rcpp.serialize(call(sqrt, 2)))
 [1] 1.414214
 # How is one to serialize the call itself
 
  rcpp.serialize(list(call(ripley)))
  [1] 58 0a 00 00 00 02 00 03 00 02 00 02 03 00 00 00 00 13 00 00 00 01 00 00 
 00 06 00 00 00 01 00 04 00 09 00 00 00 06 72 69 70 6c 65 79 00 00 00 fe
 #wrapping in a list is enough to stop evaluation
 
  eval(call(ripley))
 Error in eval(expr, envir, enclos) : could not find function ripley
  eval(list(call(ripley)))
 [[1]]
 ripley()
 
 #OK that's consistent
 
 
 Could anyone enlighten me on the evaluation mechanism? Not saying it's 
 broken, but certainly my expectations were off. Thanks
 
 
 Antonio
 ___
 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] Package built with Rcpp fails to install

[Romain Francois]

The problem is likely to be that it was assumed that List derives from RObject. 

It used to, it does not anymore. 

Classes from the api now use a policy based design. See andrei alexandrescu's 
modern c++ book for the why and the how of policy based design. 

. 

Envoyé de mon iPhone

Le 3 févr. 2014 à 20:01, Kevin Ushey kevinus...@gmail.com a écrit :

 Hi Tal,
 
 I get the same error with the new CRAN Rcpp, 0.11.0. I'll try to take
 a look later.
 
 -Kevin
 
 On Mon, Feb 3, 2014 at 10:32 AM, Tal Galili tal.gal...@gmail.com wrote:
 Dear Rcpp people,
 
 I am trying to get a new package to CRAN called {dendextendRcpp}. Here is
 the repos:
 https://github.com/talgalili/dendextendRcpp
 
 (note that this package relies on the {dendextend} which has just been
 released to CRAN today :) )
 
 
 The package loads fine for me (on R-devel, with Windows 7), however Kurt
 Hornik (CRAN maintainer) could not get the package to load on Linux.
 Following is the error massage that he got. Any input (either here or on the
 git repo) will be most appreciated.
 
 With regards,
 Tal
 
 
 
 (p.s: I suspect this might be because I use .hpp files in src. Should I use
 something else?)
 
 
 
 * installing *source* package 'dendextendRcpp' ...
 ** libs
 clang++ -std=c++11 -I/home/Hornik/tmp/R-d-clang/include -DNDEBUG
 -I/usr/local/include
 -I/home/Hornik/lib/R/Library/3.1/x86_64-linux-gnu/Rcpp/include   -fpic  -g
 -O3 -Wall -Wno-unused -pedantic -c RcppExports.cpp -o RcppExports.o
 clang++ -std=c++11 -I/home/Hornik/tmp/R-d-clang/include -DNDEBUG
 -I/usr/local/include
 -I/home/Hornik/lib/R/Library/3.1/x86_64-linux-gnu/Rcpp/include   -fpic  -g
 -O3 -Wall -Wno-unused -pedantic -c cut_lower.cpp -o cut_lower.o
 cut_lower.cpp:35:7: error: no matching function for call to 'get_height'
  if(get_height(tree) = height) {
 ^~
 ./get_branches_heights.hpp:29:8: note: candidate function not viable: no
 known conversion from 'List' (aka 'Vector19') to 'RObject' (aka
 'RObject_ImplPreserveStorage') for 1st argument
 double get_height(RObject x);
  ^
 cut_lower.cpp:36:13: error: no matching member function for call to
 'push_back'
 lower.push_back(tree);
 ~~^
 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:901:7:
 note: candidate function not viable: no known conversion from 'List' (aka
 'Vector19') to 'const value_type' (aka 'const
 Rcpp::RObject_ImplPreserveStorage') for 1st argument
 push_back(const value_type __x)
 ^
 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:919:7:
 note: candidate function not viable: no known conversion from 'List' (aka
 'Vector19') to 'value_type' (aka 'Rcpp::RObject_ImplPreserveStorage')
 for 1st argument
 push_back(value_type __x)
 ^
 cut_lower.cpp:84:7: error: no matching function for call to 'is_leaf'
  if(is_leaf( tree )) {
 ^~~
 ./is_functions.hpp:35:6: note: candidate function not viable: no known
 conversion from 'List' (aka 'Vector19') to 'RObject' (aka
 'RObject_ImplPreserveStorage') for 1st argument
 bool is_leaf(RObject x);
^
 3 errors generated.
 make: *** [cut_lower.o] Error 1
 clang++ -std=c++11 -I/home/Hornik/tmp/R-d-clang/include -DNDEBUG
 -I/usr/local/include
 -I/home/Hornik/lib/R/Library/3.1/x86_64-linux-gnu/Rcpp/include   -fpic  -g
 -O3 -Wall -Wno-unused -pedantic -c cut_lower.cpp -o cut_lower.o
 cut_lower.cpp:35:7: error: no matching function for call to 'get_height'
  if(get_height(tree) = height) {
 ^~
 ./get_branches_heights.hpp:29:8: note: candidate function not viable: no
 known conversion from 'List' (aka 'Vector19') to 'RObject' (aka
 'RObject_ImplPreserveStorage') for 1st argument
 double get_height(RObject x);
  ^
 cut_lower.cpp:36:13: error: no matching member function for call to
 'push_back'
 lower.push_back(tree);
 ~~^
 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:901:7:
 note: candidate function not viable: no known conversion from 'List' (aka
 'Vector19') to 'const value_type' (aka 'const
 Rcpp::RObject_ImplPreserveStorage') for 1st argument
 push_back(const value_type __x)
 ^
 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:919:7:
 note: candidate function not viable: no known conversion from 'List' (aka
 'Vector19') to 'value_type' (aka 'Rcpp::RObject_ImplPreserveStorage')
 for 1st argument
 push_back(value_type __x)
 ^
 cut_lower.cpp:84:7: error: no matching function for call to 'is_leaf'
  if(is_leaf( tree )) {
 ^~~
 ./is_functions.hpp:35:6: note: candidate function not viable: no known
 conversion from 'List' (aka 'Vector19') to 'RObject' (aka
 'RObject_ImplPreserveStorage') for 1st argument
 bool is_leaf(RObject x);
^
 3 errors generated.
 make: *** [cut_lower.o] Error 1
 ERROR: compilation failed for package 'dendextendRcpp'
 * removing 

Re: [Rcpp-devel] Package built with Rcpp fails to install

[Romain Francois]

Le 3 févr. 2014 à 20:35, Tal Galili tal.gal...@gmail.com a écrit :

 Dear all,
 
 Dirk - 
 I have now re-checked, and the package loads fine on my machine, and it is 
 completely synced with github.
 The only files in my gitignore are:
 .Rproj.user
 .Rhistory
 .RData
 src/*.o
 src/*.so
 src/*.dll
 So I suspect that the versions are indeed the same.
 
 Kevin - thanks.
 
 Romain - 
 I am glad you have an idea for what the problem might be. However, I am not 
 sure I understand how to proceed in fixing it.
 
 
 Since the package is very minimalistic, any specific examples on what can be 
 improved would be of great help.

My message was more or less aimee at kevin who volunteered to help you. I juqt 
wanted to give him some context. I'm sure kevin will be able to make sense of 
why i said. 

Otherwise i'll have a look, but not this week. 

Cheers, 

Romain


 
 Thanks everyone,
 Tal
 
 
 
 
 
 
 Contact 
 Details:---
 Contact me: tal.gal...@gmail.com |  
 Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) | 
 www.r-statistics.com (English)
 --
 
 
 
 On Mon, Feb 3, 2014 at 9:12 PM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 The problem is likely to be that it was assumed that List derives from 
 RObject.
 
 It used to, it does not anymore.
 
 Classes from the api now use a policy based design. See andrei 
 alexandrescu's modern c++ book for the why and the how of policy based 
 design.
 
 .
 
 Envoyé de mon iPhone
 
 Le 3 févr. 2014 à 20:01, Kevin Ushey kevinus...@gmail.com a écrit :
 
  Hi Tal,
 
  I get the same error with the new CRAN Rcpp, 0.11.0. I'll try to take
  a look later.
 
  -Kevin
 
  On Mon, Feb 3, 2014 at 10:32 AM, Tal Galili tal.gal...@gmail.com wrote:
  Dear Rcpp people,
 
  I am trying to get a new package to CRAN called {dendextendRcpp}. Here is
  the repos:
  https://github.com/talgalili/dendextendRcpp
 
  (note that this package relies on the {dendextend} which has just been
  released to CRAN today :) )
 
 
  The package loads fine for me (on R-devel, with Windows 7), however Kurt
  Hornik (CRAN maintainer) could not get the package to load on Linux.
  Following is the error massage that he got. Any input (either here or on 
  the
  git repo) will be most appreciated.
 
  With regards,
  Tal
 
  
 
  (p.s: I suspect this might be because I use .hpp files in src. Should I 
  use
  something else?)
 
 
 
  * installing *source* package 'dendextendRcpp' ...
  ** libs
  clang++ -std=c++11 -I/home/Hornik/tmp/R-d-clang/include -DNDEBUG
  -I/usr/local/include
  -I/home/Hornik/lib/R/Library/3.1/x86_64-linux-gnu/Rcpp/include   -fpic  
  -g
  -O3 -Wall -Wno-unused -pedantic -c RcppExports.cpp -o RcppExports.o
  clang++ -std=c++11 -I/home/Hornik/tmp/R-d-clang/include -DNDEBUG
  -I/usr/local/include
  -I/home/Hornik/lib/R/Library/3.1/x86_64-linux-gnu/Rcpp/include   -fpic  
  -g
  -O3 -Wall -Wno-unused -pedantic -c cut_lower.cpp -o cut_lower.o
  cut_lower.cpp:35:7: error: no matching function for call to 'get_height'
   if(get_height(tree) = height) {
  ^~
  ./get_branches_heights.hpp:29:8: note: candidate function not viable: no
  known conversion from 'List' (aka 'Vector19') to 'RObject' (aka
  'RObject_ImplPreserveStorage') for 1st argument
  double get_height(RObject x);
   ^
  cut_lower.cpp:36:13: error: no matching member function for call to
  'push_back'
  lower.push_back(tree);
  ~~^
  /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:901:7:
  note: candidate function not viable: no known conversion from 'List' (aka
  'Vector19') to 'const value_type' (aka 'const
  Rcpp::RObject_ImplPreserveStorage') for 1st argument
  push_back(const value_type __x)
  ^
  /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:919:7:
  note: candidate function not viable: no known conversion from 'List' (aka
  'Vector19') to 'value_type' (aka 'Rcpp::RObject_ImplPreserveStorage')
  for 1st argument
  push_back(value_type __x)
  ^
  cut_lower.cpp:84:7: error: no matching function for call to 'is_leaf'
   if(is_leaf( tree )) {
  ^~~
  ./is_functions.hpp:35:6: note: candidate function not viable: no known
  conversion from 'List' (aka 'Vector19') to 'RObject' (aka
  'RObject_ImplPreserveStorage') for 1st argument
  bool is_leaf(RObject x);
 ^
  3 errors generated.
  make: *** [cut_lower.o] Error 1
  clang++ -std=c++11 -I/home/Hornik/tmp/R-d-clang/include -DNDEBUG
  -I/usr/local/include
  -I/home/Hornik/lib/R/Library/3.1/x86_64-linux-gnu/Rcpp/include   -fpic  
  -g
  -O3 -Wall -Wno-unused -pedantic -c cut_lower.cpp -o cut_lower.o
  cut_lower.cpp:35:7: error: no matching function for call to 'get_height'
   if(get_height(tree) = height

Re: [Rcpp-devel] A strange question while using Rcpp

[Romain Francois]

Hello, 

This stands out 

double U; 
  for(int i=0; in; i++){
for(int j=0; jn; j++){
U = U + A_kl(i,j) * B_kl(i,j)/n/n ;
}
  } 
  U = sqrt(U);
  
U is not initialized. so all bets are on. Anything can happen. Same holds for 
aa and bb. 


Also, in terms of how you use attributes, you can at your advantage replace 
things like this: 

//[[Rcpp::export]]
double mydcov(SEXP X, SEXP Y) {
   NumericVector x = asNumericVector(X);
   NumericVector y = asNumericVector(Y);
   …
}

by things like this: 

//[[Rcpp::export]]
double mydcov(NumericVector x, NumericVector y){
   …
}

Romain

Le 19 janv. 2014 à 14:09, 晔张 zhang...@gmail.com a écrit :

 Hello, everyone. 
 I guess the probrem maybe occur because of sourceCpp(), so I have made 
 another test. I make a simple package using 
 RcppArmadillo.package.skeletion(). 
 But the same problem appear.
 My code is on Github:
 https://github.com/ZhangYet/RcppTest
 Is there anything related to my compiler or OS? I use 64-bit CentOS and g++ 
 4.4.5
 
 
 On Sat, Jan 18, 2014 at 2:01 AM, 张晔 zhang...@gmail.com wrote:
 Thanks, Dirk.
 I have upload my code to Github: https://github.com/ZhangYet/RcppTest/
 And I made a mistake:
 
 
 | res1 - mydcov(x,y)/sqrt(mydcov(x,x)*mydcov(y,y))
 |
 | a - mydcov(x,y)
 | b - mydcov(x,x)
 | c - mydcov(y,y)
 | res2 - a/sqrt(b*c)
 |
 | and res2 is different from res1.(res2 is the right answer.)
 
 I checked my test result. res2 is not the right answer, but it's different 
 from res.
 
 于 2014/1/17 21:36, Dirk Eddelbuettel 写道:
 
 On 17 January 2014 at 20:51, 晔张 wrote:
 | Dear all,
 |
 | I have a strange question such that I can't conclude it in the title.
 | I have write an function:
 | //[[Rcpp::export]]
 | double mydcov(NumericVector x, NumericVector y)
 
 It would help us to see the function to have any guess at what may be wrong.
   | This function is computing  ditance covariance. This function is OK. It 
 give
 | the right answer.
 | I use this function to compute distance correltion.
 |
 | //[[Rcpp::export]]
 | double mydcor(NumericVector x, NumericVector y)
 | {
 | return mydcov(x,y)/sqrt(mydcov(x,x)*mydcov(y,y));
 | }
 |
 | Then, I compile the source code using sourceCpp.
 | And then mydcor(x,y) give a wrong answer.
 |
 | Here comes the strange part:
 | In R, I run code as follow
 |
 | res1 - mydcov(x,y)/sqrt(mydcov(x,x)*mydcov(y,y))
 |
 | a - mydcov(x,y)
 | b - mydcov(x,x)
 | c - mydcov(y,y)
 | res2 - a/sqrt(b*c)
 |
 | and res2 is different from res1.(res2 is the right answer.)
 |
 | And I have another test, rewriting the source code for mydcor():
 | version1:
 | //[[Rcpp::export]]
 | double mydcor(NumericVector x, NumericVector y)
 | {
 | double a = mydcov(x,y)
 | double b = mydcov(x,x);
 | double c = mydcov(y,y);
 | return (a/sqrt(b*c));
 | }
 |
 | version2:
 | //[[Rcpp::export]]
 | double mydcor(NumericVector x, NumericVector y)
 | {
 | double a = mydcov(x,y)
 | Rcouta\n;
 | double b = mydcov(x,x);
 | Rcoutb\n;
 | double c = mydcov(y,y);
 | Rcoutc\n
 | return (a/sqrt(b*c));
 | }
 | This time, version2 make a right answer.
 | It's too weird. I havn't meet such situation before.
 
 I am not sure we are in a position to help you here.
 
 Regards, Dirk
 
 |
 | Happy Lunar New Year (the most important festival in China), and Thanks in
 | advance.
 |
 | Best regards
 | ZhangYet
 |
 | --
 | ___
 | 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] Bug: compileAttributes incorrectly handles Rcpp::export-ed functions with multiple arguments

[Romain Francois]

Le 18 janv. 2014 à 06:10, Davor Cubranic cubra...@stat.ubc.ca a écrit :

 Running compileAttributes with “verbose = TRUE” was very informative:
 
 $ Rscript -e 'Rcpp::compileAttributes(., TRUE)'
 Exports from /Users/davor/projects/Davor/myPackage/src/rcpp_hello_world.cpp:
List rcpp_hello_world(NumericVector foo)
 
 Exports from /Users/davor/projects/Davor/myPackage/src/rcpp_hello_world.cpp~:
List rcpp_hello_world()
 
 Answer: compileAttributes interprets Emacs backup files with extension 
 “.cpp~” as source files. (My fault for not zipping up the actual source 
 directory but the product of R CMD build.)
 
 Probable source of the error is in compileAttributes (Attributes.R:355):
 
 cppFiles - list.files(srcDir, pattern = glob2rx(*.c*”))

Hi, 

This has bitten me too in various training I gave about Rcp. I guess 
[.]c(c|pp)$ would make a better pattern. 
WRE says (if you read between the lines) that c++ files are .cpp or .cc

So this is a bug. 

Romain

 You need a better way to identify C++ sources. R-exts manual says R’s make 
 rules use .cc and .cpp for C++. (This is supposed to be recorded in 
 R_HOME/etcR_ARCH/Makeconf, so it could potentially be processed dynamically, 
 although I doubt that’s really necessary.)
 
 Davor
 
 
 On Jan 17, 2014, at 4:18 PM, Dirk Eddelbuettel e...@debian.org wrote:
 
 
 On 17 January 2014 at 15:32, Davor Cubranic wrote:
 | On 2014-01-17, at 2:55 PM, Dirk Eddelbuettel wrote:
 | 
 |  You had two mistakes here:
 |  
 |   i)   after you alter an interface to be used by Rcpp Attributes, you 
 must
 |re-run the compileAttributes() function to update the files.  See 
 the
 |vignette for details.
 | 
 | What do you mean by this? Like I said, I changed the .cpp file and re-run
 |  compileAttributes. What I uploaded is the result afterwards.
 
 The equivalent of 
 
$ cd myPackage; R -e 'Rcpp::compileAttributes(.)'
 
 For once, I launched R and typed it by hand.
 
 |(And if you use RStudio, this is done automagically)
 | 
 | So it is by devtools, on one of the functions I regularly use in my 
 workflow, perhaps test. If it wasn't, it would be such a pain.
 | 
 |   ii)  Your C++ function did not work as the 'List z = ...' parameter
 |shadowed an already declared parameter from the function interface.
 |Renaming to zz or z2 works, of course.
 | 
 | I fixed it and rerun compileAttributes. Still the same problem. New 
 version of the package is attached.
 
 See here, based on your previous file.
 
 edd@max:/tmp/davor/myPackage$ cat src/rcpp_hello_world.cpp 
 
 #include Rcpp.h
 using namespace Rcpp;
 
 // [[Rcpp::export]]
 List rcpp_hello_world(NumericVector z) {
 
CharacterVector x = CharacterVector::create( foo, bar )  ;
NumericVector y   = NumericVector::create( 0.0, 1.0 ) ;
List z2   = List::create( x, y ) ;
 
return z2 ;
 }
 edd@max:/tmp/davor/myPackage$ R CMD check .
 * using log directory ‘/tmp/davor/myPackage/..Rcheck’
 * using R version 3.0.2 (2013-09-25)
 * using platform: x86_64-pc-linux-gnu (64-bit)
 * using session charset: UTF-8
 * checking for file ‘./DESCRIPTION’ ... OK
 * checking extension type ... Package
 * this is package ‘myPackage’ version ‘1.0’
 * checking package namespace information ... OK
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking if there is a namespace ... OK
 * checking for executable files ... OK
 * checking for hidden files and directories ... NOTE
 Found the following hidden files and directories:
  ..Rcheck
 These were most likely included in error. See section ‘Package structure’ in 
 the ‘Writing R Extensions’ manual.
 * checking for portable file names ... OK
 * checking for sufficient/correct file permissions ... OK
 * checking whether package ‘myPackage’ can be installed ... WARNING
 Found the following significant warnings:
  Warning: /tmp/davor/myPackage/man/myPackage-package.Rd:31: All text must be 
 in a section
  Warning: /tmp/davor/myPackage/man/myPackage-package.Rd:32: All text must be 
 in a section
 See ‘/tmp/davor/myPackage/..Rcheck/00install.out’ for details.
 * checking installed package size ... OK
 * checking package directory ... OK
 * checking DESCRIPTION meta-information ... WARNING
 Non-standard license specification:
  What Licence is it under ?
 Standardizable: FALSE
 * checking top-level files ... OK
 * checking for left-over files ... OK
 * checking index information ... OK
 * checking package subdirectories ... WARNING
 Found the following directory with the name of a check directory:
  ./..Rcheck
 Most likely, these were included erroneously.
 * checking R files for non-ASCII characters ... OK
 * checking R files for syntax errors ... OK
 * checking whether the package can be loaded ... OK
 * checking whether the package can be loaded with stated dependencies ... OK
 * checking whether the package can be unloaded cleanly ... OK
 * checking whether the namespace can be loaded with stated 

Re: [Rcpp-devel] vector RawVector to RawMatrix [like do.call(rbind, mylist)]

[Romain Francois]

Hi, 

If you wrap your std::vectorRawVector you get a list of raw vectors, and this 
does not do deep copies of the RawVector. 

If you want a RawMatrix, you have to make copies as all the matrix data is 
contiguous in memory. 

Perhaps you can change things around, first create the matrix and then fill it 
instead of creating a vector of RawVector. 

Romain

Le 10 janv. 2014 à 10:51, Sven E. Templer sven.temp...@gmail.com a écrit :

 Hello,
 
 reading a matrix from a file and transforming it to raw format, I get a 
 std::vector Rcpp::RawVector , how can I wrap it to Rcpp::RawMatrix. 
 Right now I use Rcpp::List::create(vector RawVector ) and use 
 do.call(rbind, mylist) in R (does this do a copy to the memory?). Is there a 
 way to wrap it in C++?
 
 Thank you for your help,
 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] Question about modules

[Romain Francois]

Hello, 

You can use .factory instead of .constructor in that case. 

Romain

Le 9 janv. 2014 à 03:16, Tim Keitt tke...@utexas.edu a écrit :

 I did a little experiment with RCPP_MODULE trying to wrap a class from 
 another library. The class in question has a protected default constructor 
 and uses a non-member factory function for instantiation.
 
 In short I did not get it to work. I am assuming that if you do not include a 
 .constuctor statement, then the class does not get wrapped in the module. Is 
 that correct?
 
 THK
 
 -- 
 http://www.keittlab.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] Question about modules

[Romain Francois]

Hi, 

The module docs is probably the one in the worst shape. I think the current 
recommendation is to have this in one of your .R files: 

loadModule( yourmodule, TRUE )

which triggers a load action for when the package is loaded. 

Romain

Le 9 janv. 2014 à 17:45, Tim Keitt tke...@utexas.edu a écrit :

 OK. Not quite as automatic as I thought.
 
 Its now loading the class using 'loadRcppModules' in '.onLoad'.
 
 Still a little lost. I'll have to re-read the modules docs. Not sure how to 
 use the class. The factory did not get exposed. Do I have to expose it 
 separately eg using attributes?
 
 THK
 
 
 On Thu, Jan 9, 2014 at 10:20 AM, Tim Keitt tke...@utexas.edu wrote:
 Thanks. That at least compiles. (If anyone is curious, through 
 trial-and-error it appears .factory is not a template and takes a single 
 argument, the factory function pointer.)
 
 However I am not seeing any of my functions exported to the package. How 
 would the factory be called from R? I sort of understood that exporting in 
 packages was automatic. Do I have to manually create the module in R?
 
 THK
 
 
 On Thu, Jan 9, 2014 at 4:40 AM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Hello, 
 
 You can use .factory instead of .constructor in that case. 
 
 Romain
 
 Le 9 janv. 2014 à 03:16, Tim Keitt tke...@utexas.edu a écrit :
 
 I did a little experiment with RCPP_MODULE trying to wrap a class from 
 another library. The class in question has a protected default constructor 
 and uses a non-member factory function for instantiation.
 
 In short I did not get it to work. I am assuming that if you do not include 
 a .constuctor statement, then the class does not get wrapped in the module. 
 Is that correct?
 
 THK
 
 -- 
 http://www.keittlab.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
 
 
 
 
 -- 
 http://www.keittlab.org/
 
 
 
 -- 
 http://www.keittlab.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

Re: [Rcpp-devel] Question about modules

[Romain Francois]

not really.  the std::is_enum trait in C++11 is going to help, but not that 
much. 

Romain

Le 9 janv. 2014 à 19:02, Tim Keitt tke...@utexas.edu a écrit :

 Thanks. Got it working. Looks very promising.
 
 Any progress/work-arounds for enums? I have a ton to deal with.
 
 THK
 
 
 On Thu, Jan 9, 2014 at 11:31 AM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Hi, 
 
 The module docs is probably the one in the worst shape. I think the current 
 recommendation is to have this in one of your .R files: 
 
 loadModule( yourmodule, TRUE )
 
 which triggers a load action for when the package is loaded. 
 
 Romain
 
 Le 9 janv. 2014 à 17:45, Tim Keitt tke...@utexas.edu a écrit :
 
 OK. Not quite as automatic as I thought.
 
 Its now loading the class using 'loadRcppModules' in '.onLoad'.
 
 Still a little lost. I'll have to re-read the modules docs. Not sure how to 
 use the class. The factory did not get exposed. Do I have to expose it 
 separately eg using attributes?
 
 THK
 
 
 On Thu, Jan 9, 2014 at 10:20 AM, Tim Keitt tke...@utexas.edu wrote:
 Thanks. That at least compiles. (If anyone is curious, through 
 trial-and-error it appears .factory is not a template and takes a single 
 argument, the factory function pointer.)
 
 However I am not seeing any of my functions exported to the package. How 
 would the factory be called from R? I sort of understood that exporting in 
 packages was automatic. Do I have to manually create the module in R?
 
 THK
 
 
 On Thu, Jan 9, 2014 at 4:40 AM, Romain Francois rom...@r-enthusiasts.com 
 wrote:
 Hello, 
 
 You can use .factory instead of .constructor in that case. 
 
 Romain
 
 Le 9 janv. 2014 à 03:16, Tim Keitt tke...@utexas.edu a écrit :
 
 I did a little experiment with RCPP_MODULE trying to wrap a class from 
 another library. The class in question has a protected default constructor 
 and uses a non-member factory function for instantiation.
 
 In short I did not get it to work. I am assuming that if you do not include 
 a .constuctor statement, then the class does not get wrapped in the module. 
 Is that correct?
 
 THK
 
 -- 
 http://www.keittlab.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
 
 
 
 
 -- 
 http://www.keittlab.org/
 
 
 
 -- 
 http://www.keittlab.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
 
 
 
 -- 
 http://www.keittlab.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

Re: [Rcpp-devel] Problems wrapping stl::vectorint

[Romain Francois]

Hello, 

wrap is for converting an object of arbitrary class to an R object. It deduces 
what to do based on the class of what you pass it. So you usually don’t specify 
the template parameter. So you’d usually just write : 

return wrap(a); 

If you wanted to be explicit, then you would use: 

return wrap std::vectorint ( a ) ;

wrap returns a « SEXP » (any R object) which can be used by an IntegerVector 
constructor. So you can do: 

IntegerVector x( wrap(a) ) ;

or even:
 
IntegerVector  = asIntegerVector( wrap(a) ) ;

Romain

Le 3 janv. 2014 à 17:18, Alessandro Mammana mamm...@molgen.mpg.de a écrit :

 Dear all,
 thank you again for this fantastic library.
 Sorry for the very stupid question, I looked before posting, but I
 couldn't find anything.
 I am encountering a problem when I try to do something very basic: I
 am trying to wrap a std::vectorint to an IntegerVector:
 
 In the file scratchpad.cpp:
 
 // [[Rcpp::export]]
 IntegerVector test(){
std::vectorint a;
a.push_back(1);a.push_back(2);a.push_back(3);
return wrapIntegerVector(a);
 }
 
 when doing:
 sourceCpp(scratchpad.cpp)
 
 I get the error:
 
 scratchpad.cpp: In function 'Rcpp::IntegerVector test()':
 scratchpad.cpp:181:30: error: no matching function for call to
 'wrap(std::vectorint)'
 scratchpad.cpp:181:30: note: candidates are:
 In file included from
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/RcppCommon.h:120:0,
 from
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/Rcpp.h:27,
 from scratchpad.cpp:2:
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/Rcpp/internal/wrap.h:924:13:
 note: templateclass T SEXPREC* Rcpp::wrap(const T)
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/Rcpp/internal/wrap.h:924:13:
 note:   template argument deduction/substitution failed:
 scratchpad.cpp:181:30: note:   cannot convert 'a' (type
 'std::vectorint') to type 'const Rcpp::Vector13'
 In file included from
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/RcppCommon.h:120:0,
 from
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/Rcpp.h:27,
 from scratchpad.cpp:2:
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/Rcpp/internal/wrap.h:965:13:
 note: templateclass InputIterator SEXPREC* Rcpp::wrap(InputIterator,
 InputIterator)
 /package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include/Rcpp/internal/wrap.h:965:13:
 note:   template argument deduction/substitution failed:
 scratchpad.cpp:181:30: note:   cannot convert 'a' (type
 'std::vectorint') to type 'Rcpp::Vector13'
 scratchpad.cpp:183:1: warning: control reaches end of non-void
 function [-Wreturn-type]
 make: *** [scratchpad.o] Error 1
 g++ -I/package/mariux64/R/R-3.0.2/lib/R/include -DNDEBUG
 -I/usr/local/include
 -I/package/mariux64/R/R-3.0.2/lib/R/library/Rcpp/include-fpic
 -g -O3 -Wall -pedantic -c scratchpad.cpp -o scratchpad.o
 Error in sourceCpp(scratchpad.cpp) :
 Error 1 occurred building shared library.
 
 I must definitely be doing something very stupid. But what?
 
 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] exporting void test(void) function

[Romain Francois]

Hello, 

This is fixed in Rcpp implementations I maintain: Rcpp11 and Rcpp98 and tested 
for in Rcpp-test. 
https://github.com/romainfrancois/Rcpp11/blob/master/src/attributes.cpp#L1195
https://github.com/romainfrancois/Rcpp98/blob/master/src/attributes.cpp#L1228

Trivial to port the fix to Rcpp. 

Romain

Le 31 déc. 2013 à 05:15, Tim Keitt tke...@gmail.com a écrit :

 Apologies if this is the wrong list for user questions -- happy to be 
 redirected -- I did not see it immediately.
 
 Am I correct in noting that
 
 // [[Rcpp::export]]
 void test(void)
 {
 // do something
 }
 
 does not generate any code in RcppExports.R?
 
 Thanks.
 
 -- 
 Timothy H. Keitt
 http://www.keittlab.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] What is the most efficient method to check if a Rcpp vector contains an element?

[Romain Francois]

Thanks. 

In any case, for things like this the best thing to do is to not trust what 
anyone says and actually benchmark with realistic data. 

Romain

Le 31 déc. 2013 à 16:29, Hadley Wickham h.wick...@gmail.com a écrit :

 I believe you are mistaken. sorting is an expensive O( N log(N) ) operation.
 
 I’d use something like std::find (or std::any_of if you use C++11). Those
 are O(N)
 Otherwise, you might like Rcpp::any or Rcpp::any_of
 
 It depends on the scenario - if you want to look up M values in a
 vector of length N, then sorting + binary search will be O(M log(N) +
 N log(N)) where scanning each time will be O(MN). If M = 1, there's no
 point presorting, but if it's large, it pays to sort first.
 
 Hadley
 
 -- 
 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

Re: [Rcpp-devel] calling a homegrown cpp function from my own package when using sourceCpp

[Romain Francois]

Hi, 

If both these functions will end up in the same package, then I’d suggest to 
put both files in the src directory and use devtools::load_all on your package 
root directory. 

Dirk’s recommendation is relevant bar is in its own package and calls foo from 
another package. Might not be what you want. 

Romain


Le 30 déc. 2013 à 02:59, Søren Højsgaard sor...@math.aau.dk a écrit :

 Dear all,
 
 I have created a function c++ function foo which I export with 
 //[[Rcpp::export]]. I've put the file foo.cpp with the function into the src 
 dir of the package mypack; I've run compileAttributes and I can see the 
 function in mypack_RcppExport.h and the automatically generated interface to 
 the function is available in R (these Rcpp-attributes really make life 
 easier).
 
 Now I want to develop another function bar in the file bar.cpp and bar 
 depends on foo. I want to develop bar using sourceCpp(bar.cpp) but I can 
 not figure out how to make my c++ function foo available to bar. In bar.cpp I 
 have 
 //[[Rcpp::depends(mypack)]] but that does not make foo available.
 
 Is it possible to do what I want (I believe it is from the documentation?) or 
 is there another workaround??
 
 Happy new year - and thanks in advance!
 
 Best regards
 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] What is the most efficient method to check if a Rcpp vector contains an element?

[Romain Francois]

Le 29 déc. 2013 à 12:50, Asis Hallab asis.hal...@gmail.com a écrit :

 Dear Rcpp experst,
 
 I hope everyone has had a pleasant Xmas.
 
 I am just wondering what would be the recommended and most efficient way to 
 check, if a Rcpp Vector contains a given element?
 
 If I am not mistaken the C++ standard approach for very large std::vectors 
 would be to first sort them and then perform a binary search:
 
 http://stackoverflow.com/questions/571394/how-to-find-an-item-in-a-stdvector

I believe you are mistaken. sorting is an expensive O( N log(N) ) operation. 

I’d use something like std::find (or std::any_of if you use C++11). Those are 
O(N)
Otherwise, you might like Rcpp::any or Rcpp::any_of

Romain

 What would be the Rcpp solution for the same task on a Rcpp vector? 
 Should I convert my Rcpp Vector to a std::vector and do the above, as 
 explained on the stackoverflow blog?
 
 Cheers and a happy new year!
___
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] RcppEigen needs 1GB memory to compile

[Romain Francois]

Le 03/12/2013 12:38, Dirk Eddelbuettel a écrit :


On 2 December 2013 at 14:43, Douglas Bates wrote:
| On Mon, Dec 2, 2013 at 2:20 PM, Dirk Eddelbuettel e...@debian.org wrote:
| Do you think we should move fastLm out?
|
|
| And face the Wrath of Achim for removing a function that is described in a
| JSS paper?

We could add a 'Suggests: RcppEigenFastLm' (or whichever name we end up with).

It would help with a thing or too -- didn't you even discover a slight
NAMESPACE issue on the R side recently?

On 3 December 2013 at 08:47, Romain Francois wrote:
| without them, we (you) could deliver the packages as just headers. Most
| people depend on these packages to get the library, not to get this
| package's incantation of fastLm.
|
| I find them more useful as documentation items outside of the package,
| kind of like look how I can do fastLm with this one. This has been
| useful in training sessions for example.

Yes.  Hence my question to Doug.

And headers-only wasn't an option when fastLm() was first set up.


Of course it was. We could definitely have RcppEigen header only even 
with CRAN not header only Rcpp.


Those are two orthogonal things.


Might be time to improve on things after the 0.10.7 / 0.11.0 release.


Releasing a new version of packages that depend on Rcpp after the header 
only version is released is a cheap and good way to deal with 
compatibility issues, e.g. deal with RcppEigen expecting libRcpp.


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] RcppEigen needs 1GB memory to compile

[Romain Francois]

Le 02/12/2013 21:43, Douglas Bates a écrit :

On Mon, Dec 2, 2013 at 2:20 PM, Dirk Eddelbuettel e...@debian.org
mailto:e...@debian.org wrote:


On 2 December 2013 at 13:52, Douglas Bates wrote:
| The important thing is to use the -g0 flag.  Even though RcppEigen
is  a

Right.

And for the opencpu server deployment, you may want to edit the -g out
/etc/R/Makeconf as well. As I recall, there was an r-devel thread in
which
the desire to override such 'earlier' settings in what R CMD ...
uses via
later settings, and as I recall Simon stated that it couldn not be done.

| header-only package we include an example R function fastlm. If
you leave the
| symbols in the DLL file you get a massive library size whereas
stripping the
| symbols provides you with a much smaller file size.  And because
packages that
| use RcppEigen only use the headers, not the DLL file, it doesn't
matter if the
| symbols are stripped.

Do you think we should move fastLm out?


And face the Wrath of Achim for removing a function that is described
in a JSS paper?


If I may, I find these various fastLm function a bit of a pollution of 
packages like RcppArmadillo, RcppEigen, ...


without them, we (you) could deliver the packages as just headers. Most 
people depend on these packages to get the library, not to get this 
package's incantation of fastLm.


I find them more useful as documentation items outside of the package, 
kind of like look how I can do fastLm with this one. This has been 
useful in training sessions for example.


But now presumably, I'll get replies in the this has been there for 
years department.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] linking error when using matrices?

[Romain Francois]

Have you compiled Rcpp from source ?
If not, are you compiling with the same compiler that was used to 
compile Rcpp.


The cran binary for Rcpp 0.10.6 was built with llvm-g++ wherehas 
preseumably you are using clang now on Mavericks.


Please try compiling Rcpp from source.

Romain

Le 26/11/2013 00:59, Hao Ye a écrit :

Hi,

I just got started using Rcpp after spending a fair amount of time working in 
the two separately. I'm currently running into some errors with c++ code that 
tries to use the matrix classes in Rcpp:


library(Rcpp)
cppFunction(int mwe() {NumericMatrix mat(1,1); return 0;})


Error in 
dyn.load(/var/folders/zf/w0dsd0yn3d7czjqv5rbj9xphgn/T//RtmplA25bk/sourcecpp_fb48bcd5d63/sourceCpp_14740.so)
 :
   unable to load shared object 
'/var/folders/zf/w0dsd0yn3d7czjqv5rbj9xphgn/T//RtmplA25bk/sourcecpp_fb48bcd5d63/sourceCpp_14740.so':
   
dlopen(/var/folders/zf/w0dsd0yn3d7czjqv5rbj9xphgn/T//RtmplA25bk/sourcecpp_fb48bcd5d63/sourceCpp_14740.so,
 6): Symbol not found: 
__ZNK4Rcpp7RObject4attrERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIc
   Referenced from: 
/var/folders/zf/w0dsd0yn3d7czjqv5rbj9xphgn/T//RtmplA25bk/sourcecpp_fb48bcd5d63/sourceCpp_14740.so
   Expected in: flat namespace
  in 
/var/folders/zf/w0dsd0yn3d7czjqv5rbj9xphgn/T//RtmplA25bk/sourcecpp_fb48bcd5d63/sourceCpp_14740.so


This is the same basic error I get when I try to run the RcppGibbs.R example or 
Rcpp-unitTests.R. C==filt says the

I'm currently on OS X 10.9 with R 3.0.2 and Rcpp 0.10.6.

Does anyone know how to fix this?

Best,
--
Hao Ye
h...@ucsd.edu



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Header-only version of Rcpp provides a couple of gotcha's in RcppEigen

[Romain Francois]

Le 14/11/2013 21:34, Douglas Bates a écrit :

If I install the latest, header-only, git version of Rcpp (f117a70),
which is a great achievement by the way,


Thanks.


installation of RcppEigen
encounters a few minor problems.  One seems to be related to conflicting
definitions of trunc in Rmath.h and in fstream


Likely undoRmath is done too late. This is an Rcpp problem. Many files 
have moved around as part of making Rcpp header only



In file included from fastLm.cpp:23:
In file included from ./fastLm.h:25:
In file included from ../inst/include/RcppEigen.h:25:
In file included from ../inst/include/RcppEigenForward.h:39:
In file included from ../inst/include/unsupported/Eigen/SparseExtra:22:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/fstream:641:60:
error: no member named 'Rf_ftrunc' in 'std::ios_base'
In file included from  ios_base::openmode __mode =
ios_base::out|ios_base::trunc)
~~^
RcppEigen.cpp:22:
In file included from ../inst/include/RcppEigen.h:25:
/home/bates/build/R-devel/include/Rmath.h:In file included from
../inst/include/RcppEigenForward.h348::3915::
In file included from  note:
../inst/include/unsupported/Eigen/SparseExtra:expanded 22:
from
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/fstreammacro
:641'trunc'
:60: error: #define trunc   ftrunc
no ^
member /home/bates/build/R-devel/include/Rmath.hnamed :247'Rf_ftrunc'
:17in : 'std::ios_base'
note: expanded from macro 'ftrunc'
#define ftrunc  Rf_ftrunc
 ^
  ios_base::openmode __mode =
ios_base::out|ios_base::trunc)

The other looks like I was playing a bit fast and loose with converting
an attribute to a list

make: *** Waiting for unfinished jobs
fastLm.cpp:217:20: error: call to constructor of 'List' (aka
'Vector19') is ambiguous
 List  dimnames(NumericMatrix(Xs).attr(dimnames));
   ^~~


I'm not yet sure how to resolve this ambiguity which occupied me this 
morning. This instead should work fine:


List dimnames = NumericMatrix(Xs).attr(dimnames);


There is one more problem, but I think that needs a namespace qualifier.

fastLm.cpp:240:6: error: use of undeclared identifier
'forward_exception_to_r'; did you mean 'Rcpp::forward_exception_to_r'?
 forward_exception_to_r( ex );
 ^~
 Rcpp::forward_exception_to_r
/home/bates/R/x86_64-unknown-linux-gnu-library/3.1/Rcpp/include/Rcpp/exceptions.h:172:17:
note: 'Rcpp::forward_exception_to_r' declared here
 inline void forward_exception_to_r( const std::exception ex){
 ^


Ah. I probably moved it to the Rcpp:: namespace, these are usually 
called through the BEGIN_RCPP / END_RCPP or nowadays by compileAttributes.



Do these all look like issues that I should address in RcppEigen?


This seems more like Rcpp issues. However I'll propose a few changes to 
RcppEigen so that it uses attributes. I'll make a branch and send a pull 
request so that you can validate it.


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Header-only version of Rcpp provides a couple of gotcha's in RcppEigen

[Romain Francois]

It should be better now. My intuition about trunc was correct. Fixed in 
Rcpp (marked as 0.10.6.2).


I've also updated functions so that they use attributes rather than old 
school extern C SEXP(SEXP,SEXP,...) interfaces;


More details here:
https://github.com/RcppCore/RcppEigen/pull/2

Le 14/11/2013 21:34, Douglas Bates a écrit :

If I install the latest, header-only, git version of Rcpp (f117a70),
which is a great achievement by the way,  installation of RcppEigen
encounters a few minor problems.  One seems to be related to conflicting
definitions of trunc in Rmath.h and in fstream

In file included from fastLm.cpp:23:
In file included from ./fastLm.h:25:
In file included from ../inst/include/RcppEigen.h:25:
In file included from ../inst/include/RcppEigenForward.h:39:
In file included from ../inst/include/unsupported/Eigen/SparseExtra:22:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/fstream:641:60:
error: no member named 'Rf_ftrunc' in 'std::ios_base'
In file included from  ios_base::openmode __mode =
ios_base::out|ios_base::trunc)
~~^
RcppEigen.cpp:22:
In file included from ../inst/include/RcppEigen.h:25:
/home/bates/build/R-devel/include/Rmath.h:In file included from
../inst/include/RcppEigenForward.h348::3915::
In file included from  note:
../inst/include/unsupported/Eigen/SparseExtra:expanded 22:
from
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/fstreammacro
:641'trunc'
:60: error: #define trunc   ftrunc
no ^
member /home/bates/build/R-devel/include/Rmath.hnamed :247'Rf_ftrunc'
:17in : 'std::ios_base'
note: expanded from macro 'ftrunc'
#define ftrunc  Rf_ftrunc
 ^
  ios_base::openmode __mode =
ios_base::out|ios_base::trunc)

The other looks like I was playing a bit fast and loose with converting
an attribute to a list

make: *** Waiting for unfinished jobs
fastLm.cpp:217:20: error: call to constructor of 'List' (aka
'Vector19') is ambiguous
 List  dimnames(NumericMatrix(Xs).attr(dimnames));
   ^~~

There is one more problem, but I think that needs a namespace qualifier.

fastLm.cpp:240:6: error: use of undeclared identifier
'forward_exception_to_r'; did you mean 'Rcpp::forward_exception_to_r'?
 forward_exception_to_r( ex );
 ^~
 Rcpp::forward_exception_to_r
/home/bates/R/x86_64-unknown-linux-gnu-library/3.1/Rcpp/include/Rcpp/exceptions.h:172:17:
note: 'Rcpp::forward_exception_to_r' declared here
 inline void forward_exception_to_r( const std::exception ex){
 ^

Do these all look like issues that I should address in RcppEigen?


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] RcppArmadillo and the version of Rcpp

[Romain Francois]

Le 08/11/2013 08:14, Greg Distiller a écrit :

Hi

I hope its not inappropriate for me to post this as a follow up to my
problems with getting RcppArmadillo to work. I tried to compile from
source using R CMD INSTALL as Dirk suggested but am getting the error
message below. I don’t know if this particular problem is related to a
small issue I had getting Rcpp to work from within RStudio: for some
reason RStudio was not seeing the correct system environment path and so
could not find the compiler. I managed to resolve this by explicitly
setting the path when I start RStudio using Sys.setenv(). The error I
get when trying to install RcppArmadillo is as follows (specifically see
the errors at the bottom):

C:\Program Files\R\R-2.15.1\libraryR CMD INSTALL RcppArmadillo*tar.gz


Bad idea to have R installed in a path with spaces.


* installing to library 'C:/Program Files/R/R-2.15.1/library'

* installing *source* package 'RcppArmadillo' ...

** package 'RcppArmadillo' successfully unpacked and MD5 sums checked

** libs

*** arch - i386

cygwin warning:

   MS-DOS style path detected: C:/PROGRA~1/R/R-215~1.1/etc/i386/Makeconf

   Preferred POSIX equivalent is:
/cygdrive/c/PROGRA~1/R/R-215~1.1/etc/i386/Makec

onf

   CYGWIN environment variable option nodosfilewarning turns off this
warning.

   Consult the user's guide for more details about POSIX paths:

http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

g++  -IC:/PROGRA~1/R/R-215~1.1/include -DNDEBUG -I../inst/include
-I.   -IC:/

Program Files/R/R-2.15.1/library/Rcpp/include  -O2 -Wall
-mtune=core2 -c R

cppArmadillo.cpp -o RcppArmadillo.o

In file included from ../inst/include/RcppArmadillo.h:30:0,

  from RcppArmadillo.cpp:22:

../inst/include/RcppArmadilloForward.h:99:33: error:
'ConstReferenceInputParameter' is not a template

../inst/include/RcppArmadilloForward.h:100:33: error:
'ReferenceInputParameter' is not a template

../inst/include/RcppArmadilloForward.h:101:33: error:
'ConstInputParameter' is not a template


You likely need a newer Rcpp. Chances are you are using Rcpp  0.10.5 
and the RcppArmadillo you are trying to compiler requires Rcpp = 0.10.5



make: *** [RcppArmadillo.o] Error 1

ERROR: compilation failed for package 'RcppArmadillo'

* removing 'C:/Program Files/R/R-2.15.1/library/RcppArmadillo'

Any advice would be much appreciated.

Thanks

Greg




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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 much speedup for matrix operations?

[Romain Francois]

Le 06/11/2013 18:35, Xavier Robin a écrit :

Hi,

I have a pure-R code that spends most of the time performing vector and
matrix operations, as shown by the summary of Rprof:

   self.time self.pct total.time total.pct
%*% 903.2477.67 903.24 77.67
t.default76.26 6.56  76.26 6.56
-36.60 3.15  36.60 3.15
+24.44 2.10  24.44 2.10
/24.22 2.08  24.22 2.08
exp  20.26 1.74  20.26 1.74
predict.myClass  17.68 1.52 503.82 43.32
*11.90 1.02  11.90 1.02
t 9.38 0.81 811.94 69.82
update.batch  8.04 0.69 654.68 56.30
...

So mostly matrix %*% matrix multiplications, transpositions, vector +-/*
matrix operations and exponentiations, representing 95% of the
computation time.
I have very few loops and if/else blocks.

I want to speed up this code, and I am considering reimplementing it (or
part of it) with RcppEigen or RcppArmadillo.

However, I read that both Eigen and Amarillo use the underlying BLAS,
like R.
My question is, can I expect any significant speed-up from an Rcpp
re-implementation in this case, given it is already mostly matrix
algebra (which are supposed to be pretty efficient in R)?

Thanks,
Xavier


This very much depends on the code but there is a good chance that 
RcppArmadillo will generate code making less data copies, etc ...


Hard to say without seeing the code.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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 RcppArmadillo errors on OSX Mavericks

[Romain Francois]

___
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
+33(0) 6 28 91 30 30

___
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] Attribute does not compile with 'compileAttributes' but with 'sourceCpp'

[Romain Francois]

 description.


On Fri, Nov 1, 2013 at 1:11 PM, Simon Zehnder szehn...@uni-bonn.de wrote:
You are right, working with apple and C++ is often a mess. Up to now, llvm does 
not yet support openmp. It is coming but I do not see it fully implemented 
before next summer. If I want to use openmp I have thus to rely on the gcc 
which brings a lot of problems with it and from what I read on the R-lists most 
of the Mac Users suffer. I guess that this time a reinstall of R was 
unavoidable for most of us. I thought about using the xcrun —find gcc/g++ etc. 
to get what is needed in a Makevars but this does not give anything so far.


On 01 Nov 2013, at 17:50, Dominick Samperi djsamp...@gmail.com wrote:


With Apple moving from gcc/g++ to LLVM/clang++ I guess it makes sense
for R/Rcpp to use the LLVM/clang++ tool chain eventuallly, but I don't know
if there are plans to do this. Otherwise, the R community would need to
support MACtools following the model provided by Rtools under Windows...


On Fri, Nov 1, 2013 at 12:12 PM, Simon Zehnder szehn...@uni-bonn.de wrote:
Hi Dominick,

I did install files from brew but instead used the gcc from 
http://hpc.sourceforge.net


On 01 Nov 2013, at 16:55, Dominick Samperi djsamp...@gmail.com wrote:


If you depend on tools installed using brew, you might want to try
removing those that were installed before the Mavericks update,
using:
rm -rf /usr/local/Cellar
brew prune
brew doctor
brew install what-you-need


On Fri, Nov 1, 2013 at 11:19 AM, Simon Zehnder szehn...@uni-bonn.de wrote:
Point landing J.J.!

I already compiled a new R when Mavericks came out with a newly installed a 
gcc-4.8.2, that I can load via environment modules. I also installed th



--
Chief Scientist, RStudio
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




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Attribute does not compile with 'compileAttributes' but with 'sourceCpp'

[Romain Francois]

compileAttributes ends up calling a .Call function that lives inside Rcpp.so. 

Le 2 nov. 2013 à 10:25, Simon Zehnder szehn...@uni-bonn.de a écrit :

 Thanks Romain,
 
 looks the same here. So the path is the same, but it seems, that the padding 
 is different. I would like to understand what happens when I call 
 compileAttributes. Is there anywhere a linking involved with Rcpp.so or 
 Rcpp.dylib? 
 
 
 Best
 
 Simon
 
 
 On 02 Nov 2013, at 09:57, Romain Francois rom...@r-enthusiasts.com wrote:
 
 Le 02/11/2013 09:35, Simon Zehnder a écrit :
 First, I didn’t. But for getting some output from the functions in 
 attributes.cpp I later compiled the Rcpp package from source. When I 
 compile with the option “-headerpad_max_install_names” the 
 compileAttributes runs without an error. If I compile without this flag, I 
 get the pointer error.
 Problems with header padding is a well-known issue on the Mac 
 (https://svn.boost.org/trac/boost/ticket/1927), usually in frameworks. It 
 is used a relative path in the sections of shared objects (sometimes also 
 in dynamic libs). When the library/shared object has to be included in 
 other libraries, the relative path has to be changed to an absolute path. 
 If then there is not enough space in the header of the Mach-O file, it 
 gives you an exception.
 
 But my guess is for the compileAttributes function, that no library binding 
 is done, though it takes library paths as arguments when calling ‘.Call’. 
 My perception has been so far, that this function solely creates the 
 RcppExports.cpp and *.R files without any compilation or linking (this is 
 done later, when we compile the package with the attributes). The 
 depends/linkingto names from the DESCRIPTION file are used for headers in 
 the RcppExports.cpp file I have guessed. The point, that I am seemingly the 
 only one, that encounters this error, points me to my compiler (gcc4.8.2). 
 Could be, that under the hood clang uses already a larger header padding.
 
 Btw: When you are on Mac, could you check what “otool -L Rcpp.so” give you? 
 Is the path relative (Rcpp.so) or absolute (has it something like 
 @exectuable_path in front)?
 
 $ otool -L Rcpp.so
 Rcpp.so:
Rcpp.so (compatibility version 0.0.0, current version 0.0.0)
/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libR.dylib 
 (compatibility version 3.0.0, current version 3.0.2)

 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
  (compatibility version 150.0.0, current version 855.11.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
 1197.1.1)
 
 
 Best
 Simon
 
 On 02 Nov 2013, at 01:02, Hadley Wickham h.wick...@gmail.com wrote:
 
 Did you install Rcpp from source? That's what I had to do to solve a 
 similar problem.
 
 Hadley
 
 On Friday, November 1, 2013, Simon Zehnder wrote:
 Same thing actually on my side: I had a hardware crash lately with 10.8 
 and made fresh install after formatting my harddrive NSA-style :)
 
 Afterwards I compiled R 3.0.1 and from macports the gcc48 port as well as 
 gettext. Then, Mavericks came and I updated - nothing worked anymore: I 
 reinstalled gcc48 port and deleted R 3.0.1. Then I installed gcc4.8.2 from 
 http://hpc.sourceforge.net, Xcode Command line tools for Mavericks and 
 XQuartz 4.7.2. I work with environment modules, where I can load a certain 
 compiler with its needed environment variables. With gcc 4.8.2 I installed 
 R-3.0.2 and then the packages. Always have to type “module load 
 compilers/gcc-4.8.2 before starting R, but that doesn’t bother me … I 
 still can use openMP to its great extent :)
 
 My problem is linked to the install_name_tool and the way on Mac OS paths 
 are set and replaced in dynamic libraries …  this could of course be 
 caused by “older tools” like the llvm-gcc4.2 “laying” around…. though 
 locate does not find them….
 
 
 
 On 01 Nov 2013, at 20:33, Dominick Samperi djsamp...@gmail.com wrote:
 
 My original attempt to update to Mavericks failed (unrelated hardware 
 issue), and this
 may have actually worked in my favor. It forced me to install Mac OS X 
 10.8 from
 scratch, a clean install, that I later upgraded to Mavericks. If you 
 upgraded from
 an existing configuration you may have old tools (like llvm-g++-4.2) 
 laying around
 that could cause problems.
 
 
 On Fri, Nov 1, 2013 at 3:02 PM, Simon Zehnder szehn...@uni-bonn.de 
 wrote:
 I read through all the thread answers and my variables in the Makeconf 
 are the same alsso I installed the Xcode Command Line Tools for 
 Mavericks. Are there any other apps and libs that have been to be 
 updated? (I do not use brew). What remains is the following:
 
 Compiling Rcpp give the pointer exception (when calling 
 compileAttributes), also encountered in the thread you referred to.
 
 Compiling Rcpp and adding the flag “-headerpad_max_install_names” lets

Re: [Rcpp-devel] Fwd: CRAN packages with C++ compilation errors on OS X 10.9

[Romain Francois]

Le 31/10/2013 15:59, baptiste auguie a écrit :

Dear Rcpp gurus,

Today a CRAN maintainer informed us of the failure of a few Rcpp-related
packages to build under the new version of the Mac operating system, OS
X 10.9 aka Mavericks.
I do have access to a Mac, but I'm reluctant (in fact, unable) to update
to Mavericks, therefore I'm in the dark when it comes to fixing /testing
for the errors reported in the log file. On a positive note, it appears
at first sight that most of the errors are relatively benign, and
similar-looking issues are reported for all the packages involved. That
gives me hope that once the underlying issue is well identified, most
packages can be fixed with minimal changes.

Here's the info we were given from CRAN,

OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
headers/runtime.  Your package fails to compile with that compiler: see
the appropriate log at http://www.stats.ox.ac.uk/pub/__bdr/Mavericks/
http://www.stats.ox.ac.uk/pub/bdr/Mavericks/ .

My two packages are cda and planar. The error seems to occur in the
Modules definition, e.g. from this line in my code

https://github.com/baptiste/planar/blob/master/src/multilayer.cpp#L231

where function is judged ambiguous, as far as I understand. This
function is presumably something from
Rcpp/include/Rcpp/module/Module_generated_function.h but I am not
familiar with that code.

Any ideas, hints?

Best regards,

baptiste


I'll have a look. It is likely to be a bug in some part of Rcpp's code 
bloat.


I will try to find a solution that does not involve releasing a new Rcpp 
as 0.10.6 was just released.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Fwd: CRAN packages with C++ compilation errors on OS X 10.9

[Romain Francois]

Le 31/10/2013 15:59, baptiste auguie a écrit :

Dear Rcpp gurus,

Today a CRAN maintainer informed us of the failure of a few Rcpp-related
packages to build under the new version of the Mac operating system, OS
X 10.9 aka Mavericks.
I do have access to a Mac, but I'm reluctant (in fact, unable) to update
to Mavericks, therefore I'm in the dark when it comes to fixing /testing
for the errors reported in the log file. On a positive note, it appears
at first sight that most of the errors are relatively benign, and
similar-looking issues are reported for all the packages involved. That
gives me hope that once the underlying issue is well identified, most
packages can be fixed with minimal changes.

Here's the info we were given from CRAN,

OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
headers/runtime.  Your package fails to compile with that compiler: see
the appropriate log at http://www.stats.ox.ac.uk/pub/__bdr/Mavericks/
http://www.stats.ox.ac.uk/pub/bdr/Mavericks/ .

My two packages are cda and planar. The error seems to occur in the
Modules definition, e.g. from this line in my code

https://github.com/baptiste/planar/blob/master/src/multilayer.cpp#L231

where function is judged ambiguous, as far as I understand. This
function is presumably something from
Rcpp/include/Rcpp/module/Module_generated_function.h but I am not
familiar with that code.

Any ideas, hints?

Best regards,

baptiste


I sent you a pull request on github.

.function abuses the compiler recognition, it is just unfortunate that 
something else is called function, which is what confused it.


Not sure there could be defenses against it.

In the meantime, you should be fine by just using Rcpp::function


Also, for such trivial uses of modules (i.e. no classes), maybe it is 
worth considering using // [[Rcpp::export]] and code generation given by 
compileAttributes instead of modules.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Fwd: CRAN packages with C++ compilation errors on OS X 10.9

[Romain Francois]

Le 31/10/2013 17:36, Dirk Eddelbuettel a écrit :


On 31 October 2013 at 17:15, Romain Francois wrote:
| Le 31/10/2013 15:59, baptiste auguie a écrit :
|  OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
|  headers/runtime.  Your package fails to compile with that compiler: see
|  the appropriate log at http://www.stats.ox.ac.uk/pub/__bdr/Mavericks/
|  http://www.stats.ox.ac.uk/pub/bdr/Mavericks/ .
|
| I sent you a pull request on github.
|
| .function abuses the compiler recognition, it is just unfortunate that
| something else is called function, which is what confused it.
|
| Not sure there could be defenses against it.
|
| In the meantime, you should be fine by just using Rcpp::function

Can you think of a solution at our end that will work with existing code yet
also accomodates the newest clang version?


Maybe. This seems to be related to the functional header. We use this 
only for unary_function and binary_function, e.g. :


template typename T, typename OUT = SEXP
class unary_call : public std::unary_functionT,OUT {

We don't really need those sa they are trivial classes just there for 
the purpose of adding some typedefs:


template class Arg, class Result
  struct unary_function {
typedef Arg argument_type;
typedef Result result_type;
  };

Easy to replicate without including functional.


If you check the 'bdr' URL above you will see that this affects 10 packages,
and I recognise several (though not all) as Rcpp users.

Dirk




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] ListOf -- update

[Romain Francois]

Hi,

I'll review this when I get a chance. If we include this in Rcpp, it 
will have to be split into at least two files. Everything that uses wrap 
or as has to go in meat.


Romain

Le 29/10/2013 05:02, Kevin Ushey a écrit :

Hi guys,

With some encouragement from Romain, I took a shot at implementing the
ListOfT class. For now, everything's just in one big .cpp file here
(later I can factor it out to .h and .cpp files). But please take a
look here:

https://gist.github.com/kevinushey/7208681

I took Romain's suggestions from before and 1) have ListOfT
inheriting from List directly, and 2) proxified operator[] so we can
distinguish read / write (merci, Scott Meyers, for More Effective
C++). Ultimately, most of it is boilerplate used so that the proxy is
handled correctly.

The class isn't too complicated, but it is surprisingly functional
since it can leverage everything already available in Rcpp. It works
well with the sugar functions and it can be handled by Rcpp attributes
as-is as well. There are a couple of demonstrative examples at the
bottom (to be written as a more formal test suite later).

I would welcome any comments; I'm fairly inexperienced as a C++
programmer so I'm sure some things might be wrong.


You're on the right track.


Things I know could be better and would appreciate some advice on:

1) Use Rcpp's traits system rather than TYPEOF for mapping template
types to strings (ie. in validate), (eg: going from Rcpp classes to
internal SEXP types; more generally, how can I navigate the traits
namespace),

2) Extend lapply, sapply to infer types for applied templated
functions from ListOfT classes, so for e.g. a ListOfNumericVector
x and a template function add_1, we could just write

 lapply(x, add_1);

rather than

 lapply(x, add_1NumericVector);

Thanks!

-Kevin



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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/C++ serialization of R objects?

[Romain Francois]

Le 29/10/2013 16:24, Rodney Sparapani a écrit :

Hi Gang:

I have been through the docs, and if this is answered, then I missed
it.  Is there a recommended way to serialize an R object with Rcpp?


Not at the moment. It is pretty easy though to make an R call to saveRDS 
using Function ...


Environment base = Environment::base_namespace() ;
Function saveRDS[ saveRDS ] ;

List precious = ... // whatever you want to saveRDS
saveRDS( precious, somefile) ;


For example, suppose I have created a List in C++ and I want to store
it with the R equivalent of saveRDS() because I want to read it in at
some point later on from within R via readRDS().

More details if needed...  I am doing some long-running MCMC
calculations.  And, I would like the C++ code to store the
results every, say, 1 iterations.  Of course, I could do
this in a loop from R.  But, I want to be sure that is really
necessary before I re-write my R code ;o)



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] inline error

[Romain Francois]

Just a warning that this code creates a NumericVector of length 1 initialised 
with 0. 

1 is not a NumericVector so the compiler looks for a conversion, the one that 
is found is the ctor for NumericVector that takes an int. 

Romain

Le 28 oct. 2013 à 17:05, Hadley Wickham h.wick...@gmail.com a écrit :

 FYI, that's equivalent to the somewhat cleaner
 
 library(Rcpp)
 cppFunction(NumericVector x(NumericVector start) {
  return 1;
 })
 
 Hadley
 
 On Mon, Oct 28, 2013 at 8:58 AM, Simon Zehnder szehn...@uni-bonn.de wrote:
 Dear Rcpp::Users and Rcpp::Devels,
 
 I get a weird error when using inline and I want to know, where it comes 
 from. I run the following code:
 
 library(Rcpp)
 library(inline)
 cfunc - cxxfunction(signature(start=vector), body = Rcpp::NumericVector 
 x(start); return 1;, plugins = Rcpp”)
 
 And I get the following Error:
 
 Error in compileCode(f, code, language = language, verbose = verbose) :
  Compilation ERROR, function(s)/method(s) not created! file1606062c0507.cpp: 
 In function ‘SEXPREC* file1606062c0507(SEXP)’:
 file1606062c0507.cpp:19:1: error: ‘Rcpp’ has not been declared
 Rcpp::NumericVector x(start); return 1;
 ^
 file1606062c0507.cpp:19:21: error: expected ‘;’ before ‘x’
 Rcpp::NumericVector x(start); return 1;
 ^
 file1606062c0507.cpp:19:38: error: invalid conversion from ‘int’ to ‘SEXP’ 
 [-fpermissive]
 Rcpp::NumericVector x(start); return 1;
  ^
 make: *** [file1606062c0507.o] Error 1
 In addition: Warning message:
 running command '/Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB 
 file1606062c0507.cpp 2 file1606062c0507.cpp.err.txt' had status 1
 
 Best
 Simon
 
 ___
 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
 
 
 
 -- 
 Chief Scientist, RStudio
 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
___
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] feature proposal: ListOf

[Romain Francois]

Cool. I've got lots on my plate right now, so this is not a priority.
Did you have a chance to look at the (simplistic) implementation of 
ListOf in dplyr: 
https://github.com/hadley/dplyr/blob/master/inst/include/tools/ListOf.h


The indexing operator should be proxified so that we could handle 
assignments, i.e.:


NumericVector z ;
ListOfNumericVector x( xxx );
x[0] = z ;

At the moment it only has read access because that's all I needed for 
now in dplyr.


So maybe if we wanted something more generic in Rcpp, this should be 
designed a bit more.


Romain

Le 25/10/2013 20:40, Kevin Ushey a écrit :

Hi Romain, Dirk,

I'd be willing to contribute an Rcpp Gallery post and some tests if
this were added to Rcpp; I think it would be quite useful.

-Kevin

On Wed, Oct 23, 2013 at 6:31 AM, Dirk Eddelbuettel e...@debian.org wrote:


On 23 October 2013 at 14:31, Romain Francois wrote:
| Le 23/10/2013 13:47, Dirk Eddelbuettel a écrit :
|  As always, preferably with a usage example (Rcpp Gallery post?  Section in 
a (new)
|  vigntte?) and tests so that people have some info on how to use it.
|
| That means it will take me more time than what I wanted to commit to
| this. I'll come back to it later then.

Up to you.  FWIW your previous commits are still undocumented in NEWS.Rd.

Dirk

--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Exporter.h cannot convert 'SEXP' to 'const std::vectordouble*' in initialization

[Romain Francois]

Le 23/10/2013 06:12, jean-michel.perr...@csiro.au a écrit :

Hi,

This has to be a basic question, but I cannot figure out what I am missing nor 
see quite similar pre-existing posts.

I am trying to create an Rcpp module around a class (generated C++ proxy 
class). The environment is Rcpp 0.10.5 on Windows, R 3.0.2 x64 and RTools 3.0.

R CMD INSTALL spits the dummy at compilation(?) time when the Exporter things kick in, with the 
message  cannot convert 'SEXP' to 'const std::vectordouble*' in 
initialization on the 'Play' method as per below.

class SimulationExport {
public:
   SimulationExport();
   ~SimulationExport();
   void Execute(void);
   void Play(const char* name, const std::vectordouble* values);
// other methods snipped
}

RCPP_MODULE(SimulationEx){
 class_SimulationExport( Simulation )
// snipped
 .method( play, SimulationExport::Play)
// snipped
}

I don't get why it cannot wrap a vectordouble given how similar it is to 7.2.2.7 Full 
Example in the  Seamless R and C++ Integration with Rcpp book. The same sample code 
created with Rcpp.package.skeleton compiles (though it fails check on load, BTW). The only difference is 
the presence of a 'const' modifier before the vector, but removing it does not solve the issue.

Rcpp.package.skeleton('sampleRcpp', module=TRUE, author='J-M')
library(devtools)
check('sampleRcpp') # passes past the compilation step.

Cheers,
J-M


As Dirk said, don't use a pointer to a std::vectordouble.

What do you do in Play with this vector ?
Why did you want to pass it as a pointer ? If this was for performance, 
then passing a reference won't cut it because Rcpp cheats and when you 
pass a reference as a parameter to a function that is Rcpp::export'ed, 
what happens is that the data gets copied.


Could you instead pass down an NumericVector ? The reason is that given 
Rcpp's design, copy semantics of NumericVector are cheap (no data copy). 
Which leads back to hte original question: what does Play want to do 
with this vector ?


Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Local .h files and Rcpp attributes

[Romain Francois]

Le 19/10/13 22:06, JJ Allaire a écrit :

For it to actually work though we'd need to modify Makevars as well (as
Romain pointed out) so that the RcppExports.cpp could see the include
file.


IMO, R should do this. R should recognize that a package has a 
inst/include directory and automatically set the -I flag.


Maybe it is something that can be negociated with the core team.


This might get trickly. My thought was that we should either
generate a fully working solution or failing that generation enough
pointers/documentation to get most users over the hump.

J



On Sat, Oct 19, 2013 at 3:56 PM, Dirk Eddelbuettel e...@debian.org
mailto:e...@debian.org wrote:


On 19 October 2013 at 15:40, JJ Allaire wrote:
|
| Maybe you could follow the example of Rcpp.package.skeleton()
and just drop
| an empty yet amply commented file there?  By being there
users have a
| better chance of stumbling over it :)
|
|
| Since this would involve creating a new directory (inst/include)
perhaps I
| could instead emit comments at the top of RcppExports.cpp
explaining the
| mechanism?

True, but maybe I'd still go for it.  inst/include/ is after all the
place
via which a any package foo can provide its headers to another
package bar
which simply adds 'LinkingTo: foo'.

Currently, the 'cost' of attributes is one extra RcppExports.R, one
RcppExports.cpp and we'd add a new (small, few lines with comments)
header
file in a new directory.  Seems fair to me -- but entirely your call.

Restraint in not cluttering user systems is also a good thing. We'd
be back
to the need for more/better documentation though.

Dirk

--
Dirk Eddelbuettel | e...@debian.org mailto:e...@debian.org |
http://dirk.eddelbuettel.com





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Local .h files and Rcpp attributes

[Romain Francois]

Le 19/10/13 22:37, JJ Allaire a écrit :

Another alternative would be to create a new mechanism: an
RcppExports.h file written into src (and thus not requiring
modification of Makevars). This could include a comment explaining
that anything extra the user wants in RcppExports.cpp should be
declared there.


I don't like this. I think we should encourage people to use 
inst/include eitrher by doing it automatically as part of 
compileAttributes or by means of documentation.




On Oct 19, 2013, at 4:15 PM, Dirk Eddelbuettel e...@debian.org wrote:


On 19 October 2013 at 16:06, JJ Allaire wrote:
| For it to actually work though we'd need to modify Makevars as well (as Romain
| pointed out) so that the RcppExports.cpp could see the include file. This 
might
| get trickly.

Well right now we simply set people up to fail / having to create it
themselves. Rcpp.package.skeleton() has always created src/Makevars{.win} but
currently does not include PKG_CPPFLAGS = ...  Maybe it should. Anyway...

| My thought was that we should either generate a fully working
| solution or failing that generation enough pointers/documentation to get most
| users over the hump.

The thread is long enough, so maybe the next someone struggles with this they
may find. If someone is itching to fix this, we will gladly take patches.

Dirk

--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] feature proposal: ListOf

[Romain Francois]

Hello,

Another thing I have developped in dplyr but might be generally useful 
is the ListOf class. See 
https://github.com/hadley/dplyr/blob/master/inst/include/tools/ListOf.h


The idea is to embed, by means of the template parameter what this list 
contains. Of course it is only usable if the list contains only objects 
that are compatible with the type.


So if we knew we had a list of numeric vector, we could use :

ListOfNumericVector, or ListOf std::vectordouble 

so that when we use LisOf extracting operator, we know what we get. This 
is something I've shared a few times on mailing list and SO, but could 
be generally useufl for Rcpp users.


Do people want to see this in Rcpp.

This is orthogonal to everything else, so the risk is minimum. This is a 
template class, so the cost is null if the class is not used.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] max length of Rcpp::List is 20 elements?

[Romain Francois]

Le 21/10/2013 11:59, Florian Oswald a écrit :

Dear all,

I've noted that I cannot return an Rcpp::List longer than 20 elements.
In particular, this here compiles:

library(Rcpp)
library(inline)

src - '
List out = List::create(_[x1] = 1,
_[x2] = 2,
_[x3] = 3,
_[x4] = 4,
_[x5] = 5,
_[x6] = 6,
_[x7] = 7,
_[x8] = 8,
_[x9] = 9,
_[x10] = 10,
_[x11] = 11,
_[x12] = 12,
_[x13] = 13,
_[x14] = 14,
_[x15] = 15,
_[x16] = 16,
_[x17] = 17,
_[x18] = 18,
_[x19] = 19,
//_[x20] = 20,
_[x21] = 21);

return out;'

f - cxxfunction(body=src,plugin='Rcpp')
f()

whereas it does not if you uncomment element x20 with the error message

no matching function for call to
‘Rcpp::Vector19::create(Rcpp::traits::named_objectint, ...

from which I deduce that the Rcpp::List is an Rcpp::Vector of length 20.
Was there any strong reason to stop at 20 elements?

Best,
Florian


create is implemented as a set of overloads that are generated by code 
bloating. see this: 
https://r-forge.r-project.org/scm/viewvc.php/pkg/Rcpp/inst/include/Rcpp/generated/Vector__create.h?view=markuprevision=4207root=rcpp


It would be trivial to go beyond 20, but that would mean that Rcpp would 
have to carry additional bloat.


Instead, you can do something like the code in this gist. 
https://gist.github.com/romainfrancois/7117540


List out( 30 ) ;
CharacterVector names(30) ;

set_item( out, 0 , _[x0]  = 42, names) ;
...
set_item( out, 25 , _[x24]  = 42, names) ;


If this syntax is too much to stomach, you can smart up and write some 
sort of proxy class like in: https://gist.github.com/romainfrancois/7117691


In this example, you write:

List out( 30 ) ; CharacterVector names(30) ;
SequentialInserter inserter( out, names );

inserter[x0]  = 42  ;
...
inserter[x29] = 32 ;

You can probably encapsulate more so that you don't have to create the 3 
objects (out, names and inserter), but I leave this as an exercize.


This is not as nice as using create, but it gets the job done in a way 
that does not compromise the structure you wanted to use in the first 
place, as was suggested otherwise in this thread.


FYI, in Rcpp11, create has been reimplemented to take advantage of 
variadic templates (from C++11), so this limitation disappears.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] feature proposal: ListOf

[Romain Francois]

Le 23/10/2013 13:47, Dirk Eddelbuettel a écrit :


On 21 October 2013 at 14:32, Romain Francois wrote:
| Hello,
|
| Another thing I have developped in dplyr but might be generally useful
| is the ListOf class. See
| https://github.com/hadley/dplyr/blob/master/inst/include/tools/ListOf.h
|
| The idea is to embed, by means of the template parameter what this list
| contains. Of course it is only usable if the list contains only objects
| that are compatible with the type.
|
| So if we knew we had a list of numeric vector, we could use :
|
| ListOfNumericVector, or ListOf std::vectordouble 
|
| so that when we use LisOf extracting operator, we know what we get. This
| is something I've shared a few times on mailing list and SO, but could
| be generally useufl for Rcpp users.
|
| Do people want to see this in Rcpp.

Sure.

As always, preferably with a usage example (Rcpp Gallery post?  Section in a 
(new)
vigntte?) and tests so that people have some info on how to use it.


That means it will take me more time than what I wanted to commit to 
this. I'll come back to it later then.



| This is orthogonal to everything else, so the risk is minimum. This is a
| template class, so the cost is null if the class is not used.

And R-Forge is currently healthy so we do get build and test reports within
about 24 hours of a commit too.

Dirk




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Local .h files and Rcpp attributes

[Romain Francois]

Le 19/10/13 05:13, Mark Fredrickson a écrit :

Hello,

Short version: Is it possible to instruct the code generator in
`compileAttributes` to source local header files when generating
RcppExports.cpp?

Long version: I'm trying to crib from the Dirk's examples in his recent
UCB talk examples about function pointers
(http://dirk.eddelbuettel.com/papers/rcpp_booth_uofc_oct2013-part2.pdf).
In it, he uses a `typedef` to define the type of his function call. This
is all great if using `sourceCpp` to slurp in the file directly, but I'm
getting errors when compiling a package. I'd like to use attributes to
export my functions at both the R level and as the target of function
pointers, but this may be incompatible with attributes, at least at some
level.

My (perhaps naive) attempts are giving errors about my `funcPtr` type
not being defined. I've tried moving this definition to a header file,
but even with `//[[Rcpp::depends(myheader)]]` or
`\\[Rcpp::depends(myheader.h)]]`, the generated RcppExports.cpp file
does not include `myheader.h`.

My (non-working) code can be found at:

https://github.com/markmfredrickson/RItools/blob/ri-rcpp/src/teststatistics.cpp

Thanks in advance,

-M


Hello,

Try putting your declarations into a RItools.h file in inst/include/ or 
src/ in your package, i.e. have this in RItools.h


typedef double (*testStat)(NumericVector, NumericVector);

and add:

PKG_CPPFLAGS += -I../inst/include/

to your Makevars and Makevars.win.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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 Makevars COPYING policy?

[Romain Francois]

Jonathan, Rconsider the // [[Rcpp::interfaces(cpp)]] attribute. That is 
documented in the attributes vignette.


In essence, in the host package (called host here), you have this in 
your C++ file:


#include Rcpp.h
using namespace Rcpp;

// [[Rcpp::interfaces(cpp)]]

// [[Rcpp::export]]
NumericVector fun() {
return rnorm(10) ;
}

// [[Rcpp::export]]
NumericVector foo(double x) {
return rnorm(10) ;
}

With Rcpp::interfaces(cpp) you express that you want these functions 
available at the C++ layer in client packages.


Then you call compileAttributes and build the host package.


Now, when you want to use it in the client package, you do:
- add LinkingTo: host in client's DESCRIPTION
- include the host.h file
- refer to functions from host with the host:: namespace in C++ code, e.g. :

#include host.h

// [[Rcpp::export]]
List do_stuff() {

List res = List::create(
host::foo(2.),
host::fun()
) ;
return res ;
}


That's it. The code generated by compileAttributes takes care of 
registering and retrieving the functions.


Romain

Le 16/10/13 04:34, Jonathan Olmsted a écrit :

Finally, some closure...

Romain, as you sensed, I did not *really* need linking. Of course, I did
not realize that earlier. You were completely right to point in the
direction of registering functions. And, while I wish this was some new
feature, it's been in R for a *long* time. How the answer could be
mentioned in R-exts with me completely missing it I have no idea (but
I'm not surprised, I guess).

It took me longer than I'm willing to reveal to get the functions
registered in the host package (if you will). It then took me another
similarly long block of time to figure out function pointers. And, it
then took me a third one of these blocks to figure out how LinkingTo
factored in (prior to this, I'd been calling R_GetCCallable on the
client package side. However, I finally got that squared away after
working through the Rcpp11 repo. As you well know, this approach is
impressively clean from the perspective of the client package. Just
include a header and you are done.

Darren, I thought I'd just ask about permission first before making
someone think hard about an already solved problem. But, that's a clever
idea all the same.

One sticking point for me was inferring the general from that the
examples (e.g., Rcpp11, Matrix) which used slightly different approaches
and, of course, had other moving parts.

Dirk, If I just looked in the right spot of xts, I'd have seen the
header trick on the host package spelled out in plain English. *sigh*

In general, I'm quite curious how widely used this is (just a matter of
a script over the DL-ed ReverseDepends of Rcpp packages) . It'd be a
shame for devs not to use it more and expose their functionality.

Many thanks for everyone's help!

-Jonathan






-
J.P. Olmsted
j.p.olms...@gmail.com mailto:j.p.olms...@gmail.com
http://about.me/olmjo
-



On Tue, Oct 15, 2013 at 7:01 PM, Darren Cook dar...@dcook.org
mailto:dar...@dcook.org wrote:

  Intellectual property rights confuse the heck out of me so I
wanted to ask
  explicitly before stepping on any toes. Rcpp is GPL-2. However, the
  Makevars in the ./src/ directory don't necessarily carry the same
license
  header as your Cpp source. What are your intentions for
derivative use of
  the Makevars files you guys use in Rcpp? Specifically, I would
like to use
  your strategy in an R package to build a static lib for
subsequent linking
  against by other R packages.

You could also describe your actual need on StackOverflow; IIRC the
terms and conditions explicitly say all code posted there can be treated
as public domain.

If someone gives you the same approach then perhaps there is only one
way to do it; if someone gives you a different way perhaps that will be
just as good.

Darren

P.S. This idea falls flat if someone just says take a look at the Rcpp
Makevars file ;-)

___
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




___
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
+33(0) 6 28 91 30 30

___
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] Calling an internal do_* C level function

[Romain Francois]

Le 15/10/13 10:46, Martyn Plummer a écrit :

On Mon, 2013-10-14 at 22:24 +0200, Romain Francois wrote:

Le 14/10/13 21:47, Mark Fredrickson a écrit :

Thank you to Romain and Dirk. I've seen some C++ rank implementations,
and I'll probably copy one of those.

 Lastly, not a milligram of Rcpp in this question. Plain R programming
 questions should go to r-devel, not rcpp-devel.


Noted. My apologies. I was hoping there was some magic/sugar for this
particular problem that I had missed in the docs. Perhaps something that
negotiated the look up table that R uses for these functions.

-M


Here comes the magic.

The internal function table (R_FunTab) is not hidden. With a bit of
copying from R's unexported Defn.h, you can get the function pointer for
the internal rank. see this gist:
https://gist.github.com/romainfrancois/6981372

However, if you do this in a package, there is a good chance R CMD check
will moan about it because you use R_FunTab.

Romain


Calling non-API functions and subverting the mechanism for hiding them
is a good way to make yourself unpopular.


I agree that one should not do that. It was just a fun challenge. I 
usually don't like can't do that. Note that the example did not 
completely subvert it, there would have been a message complaining about 
the use of the R_FunTab symbol.


But I agree with you that in this example, and in many other examples, 
the STL provides the right tool.


Romainx


Anyway, Mark wants to use the rank() function from R. So here is some
code that I used to emulate it JAGS using the STL stable_sort algorithm.

//Create a vector of pointers to the elements of args and sort it
vectordouble const* argptrs(N);
for (int i = 0; i  N; ++i) {
argptrs[i] = args + i;
}
stable_sort(argptrs.begin(), argptrs.end(), lt_doubleptr);

//Ranks can be inferred from the sorted vector of pointers
for (int i = 0; i  N; ++i) {
value[argptrs[i] - args] = i + 1;
}

Here args is an array of doubles containing the input vector, value
is an array to hold the output vector, both of length N, and
lt_doubleptr is a comparison function that works on the vector of
pointers:

static bool lt_doubleptr (double const *arg1, double const *arg2) {
   return *arg1  *arg2;
}

Martyn



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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 Makevars COPYING policy?

[Romain Francois]

Le 15/10/13 21:27, Jonathan Olmsted a écrit :

Dirk and Romain (in the order listed in the file mentioned below),

Intellectual property rights confuse the heck out of me so I wanted to
ask explicitly before stepping on any toes. Rcpp is GPL-2. However, the
Makevars in the ./src/ directory don't necessarily carry the same
license header as your Cpp source. What are your intentions for
derivative use of the Makevars files you guys use in Rcpp? Specifically,
I would like to use your strategy in an R package to build a static lib
for subsequent linking against by other R packages.

Many thanks!

-Jonathan


Personally I find these licence headers redundant with the declaration 
in the DESCRIPTION file.


As far as I'm concerned, unless otherwise specified, whatever is in Rcpp 
is GPL-2.



Now, are you sure you need linking?

One alternative I tend to use now is to define as much as possible (and 
perhaps all) in headers, and use the R mechanism if I really need to 
have a function in a .cpp file.

http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines

In Rcpp11, I've implemented this and I don't have the Makevars anymore. 
This makes extending easier as all the client package needs is to use 
LinkingTo to pull in headers from inst/include.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] calling R function triggers tryCatch() ???

[Romain Francois]

 = no_init(n);

   Language call(FUN, R_NilValue);
   Language::Proxy proxy(call, 1);
   for (int r = 0; r  n; r++) {
 proxy = x(r, _) ;
 result[r] = asdouble(call.fast_eval() );
   }
   return result;
}


M - matrix(rnorm(15L), nrow=3L);
identical(rowMeans(M), apply(M, 1L, mean));

[1] TRUE

identical(rowMeans(M), rowApply0(M, mean));

[1] TRUE

identical(rowMeans(M), rowApply1(M, mean));

[1] TRUE

identical(rowMeans(M), rowApply2(M, mean));

[1] TRUE

benchmark(rowMeans(M),

+   apply(M, 1L, mean),
+   rowApply0(M, mean),
+   rowApply1(M, mean),
+   rowApply2(M, mean),
+   replications=30L);
 test replications elapsed relative user.self sys.self
user.child sys.child
3 rowApply0(M, mean)   30   23.268.551 23.140
NANA
2  apply(M, 1, mean)   30   21.307.831 21.130
NANA
4 rowApply1(M, mean)   30   10.233.761 10.220
NANA
5 rowApply2(M, mean)   309.873.629  9.820
NANA
1rowMeans(M)   302.721.000  2.720
NANA


M - matrix(rnorm(1500L), nrow=30L);
benchmark(rowMeans(M),

+   apply(M, 1L, mean),
+   rowApply0(M, mean),
+   rowApply1(M, mean),
+   rowApply2(M, mean),
+   replications=3L);
 test replications elapsed relative user.self sys.self
user.child sys.child
3 rowApply0(M, mean)3   21.32   48.455 21.300
NANA
2  apply(M, 1, mean)3   11.17   25.386 11.170
NANA
4 rowApply1(M, mean)38.24   18.727  8.190
NANA
5 rowApply2(M, mean)38.10   18.409  8.080
NANA
1rowMeans(M)30.441.000  0.430
NANA


M - matrix(rnorm(15L), nrow=300L);
benchmark(rowMeans(M),

+   apply(M, 1L, mean),
+   rowApply0(M, mean),
+   rowApply1(M, mean),
+   rowApply2(M, mean),
+   replications=3000L);
 test replications elapsed relative user.self sys.self
user.child sys.child
3 rowApply0(M, mean) 3000   26.65   18.379 26.41 0.01
NANA
2  apply(M, 1, mean) 3000   19.76   13.628 19.71 0.00
NANA
4 rowApply1(M, mean) 3000   12.798.821 12.78 0.00
NANA
5 rowApply2(M, mean) 3000   12.698.752 12.68 0.00
NANA
1rowMeans(M) 30001.451.000  1.45 0.00
NANA

again, as Romain suggested, implementation rowApply2 is faster than
rowApply1, and rowApply0 (which triggers tryCatch) is even slower than R's
apply.

Thanks 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




--
Chief Scientist, RStudio
http://had.co.nz/







--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Issue with Matrices and Iterators

[Romain Francois]

Le 14/10/13 21:21, Alessandro Mammana a écrit :

Hi all,
I have very little experience with Rcpp and also with c++, so I am
sorry if my question might be too stupid.
I am trying to use iterators in my code, because I understand them
better than vectors, because they should be efficient, and because I
should be able to combine different implementations of vector and
matrix classes. However the following code does not compile:

#include Rcpp.h
using namespace Rcpp;

typedef NumericVector::iterator DoubleIter;

double sum(DoubleIter b, DoubleIter e){
 double sum = 0;
 while (b!=e){
 sum += *(b++);
 }
 return sum;
}

// [[Rcpp::export]]
double sumFirstRow(NumericMatrix mat){
 return sum(mat(0,_).begin(), mat(0,_).end());
}

The error message is not very useful (or at least I cannot interpret it):

In function 'double sumFirstRow(Rcpp::NumericMatrix)':
error: no matching function for call to
'sum(Rcpp::MatrixRow14::iterator, Rcpp::MatrixRow14::iterator)'
note: candidates are:
note: double sum(DoubleIter, DoubleIter)
note: no known conversion for argument 1 from
'Rcpp::MatrixRow14::iterator' to 'DoubleIter {aka double*}'

Am I missing something very basic?
Thanks a lot!
Ale


mat(0,_).begin() gives you an object that acts 	as an iterator over the 
first row. This is not the same thing as an iterator over a vector.


 demangle( NumericVector::iterator )
[1] double*
 demangle( NumericMatrix::Row::iterator )
[1] Rcpp::MatrixRow14::iterator


The first part of what you are missing is templates: you should define 
you sum function like this:


template typename Iterator
double sum(Iterator b, Iterator e){
double sum = 0;
while (b!=e){
sum += *(b++);
}
return sum;
}

although, this is not generic enough, in situations where you iterate 
over the first row of an integer matrix, you should not use double, but 
int. So you can do something like this:


template typename Iterator
typename traits::remove_reference typename 
std::iterator_traitsIterator::value_type::type sum(Iterator b, 
Iterator e){
typedef typename traits::remove_referencetypename 
std::iterator_traitsIterator::value_type::type STORAGE ;

STORAGE sum = 0;
while (b!=e) sum += *(b++);
return sum;
}

A bit more involved, but more generic.

Lastly, you can also recognize that this is in fact an algorithm from 
the STL: accumulate, so you can do something like this;



// [[Rcpp::export]]
double sumFirstRowSTL(NumericMatrix mat){
return std::accumulate(mat(0,_).begin(), mat(0,_).end(), 0.0);
}

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Calling an internal do_* C level function

[Romain Francois]

Le 14/10/13 21:47, Mark Fredrickson a écrit :

Thank you to Romain and Dirk. I've seen some C++ rank implementations,
and I'll probably copy one of those.

Lastly, not a milligram of Rcpp in this question. Plain R programming
questions should go to r-devel, not rcpp-devel.


Noted. My apologies. I was hoping there was some magic/sugar for this
particular problem that I had missed in the docs. Perhaps something that
negotiated the look up table that R uses for these functions.

-M


Here comes the magic.

The internal function table (R_FunTab) is not hidden. With a bit of 
copying from R's unexported Defn.h, you can get the function pointer for 
the internal rank. see this gist: 
https://gist.github.com/romainfrancois/6981372


However, if you do this in a package, there is a good chance R CMD check 
will moan about it because you use R_FunTab.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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 testing

[Romain Francois]

Le 13/10/13 20:47, Dominick Samperi a écrit :

Hello Romain,

I tested Rcpp11 under Mac OS (10.8.5) using Apple's
clang-500.2.75 (Xcode 5), and also under Linux. Here are
some results:

1. The recommended install method
 devtools::install_github(romainfrancois/Rcpp11)
 did not work. The problem seems to be that it looks at
 hadley's github repo instead of yours? The work-around is
 simply to download the zip file.


This should work with the devel version of devtools. This is a recent 
addition to devtools. 
https://twitter.com/hadleywickham/status/387303629952401409



2. Under Mac OS inclusion of internal.h causes compilation to fail
 because CALLFUN_1 defines a function with no 'extern C'
 linkage specification, while RCPP_FUN_1 defines the same
 function with this linkage specification.

 The error results from
 improved compliance with the standards: C++98 and C++11
 standards (Section 7.5.1) state that two function types with
 with different linkage are different types, yet one cannot
 overload the other because you cannot overload on the
 return type (which arguably includes the linkage).

The work-around is to insert extern C in the CALLFUN_xx
macros in internal.h. This is also needed in the declaration of
init_Rcpp11_routines() in internal.h.


I'll go the opposite way actually, and not use c linkage at all, and 
perhaps have them in Rcpp's namespace.

Since these are registered, we don't need C linkage.


3. The default file system type under Mac OS uses case-insensitive
 file names (like Windows), whereas Linux file systems use
 case-sensitive file names. This can cause builds that work
 under Mac OS to fail under Linux, and this happens with
 Rcpp11: for example, Rcpp/Vector.h includes Rcpp/Na_Proxy.h,
 yet the file that exists on disk is Rcpp/NA_Proxy.h.


Thanks. I'll fix that.


 Thus periodic testing on systems with file name case-sensitivity
 can prevent big porting and refactoring headaches.

Cheers,
Dominick


Comments: Rcpp11 is in heavy development, so I'm not too concerned about 
these too much yet.


In any case, for things like that, please use the issue tracker:
https://github.com/romainfrancois/Rcpp11/issues?state=open

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Armor, Shield and Shelter.

[Romain Francois]

Hello,

As usual when I work on some packge that use Rcpp, I come up with ideas. 
On dplyrRcpp I've defined these classes to handle stack based protection 
of objects from the GC. These are thin wrappers around PROTECT / 
UNPROTECT / PROTECT_WITH_INDEX


Sometimes, the Rcpp api classes don't quite cut it and one has to 
directly manipulate SEXP. When we do that we have to surrender to use 
the ugly PROTECT/UNPROTECT macros and whenever I use them, I feel 
unsafe, because later on I will forget to correctly unprotect, ...


Anyway, I'd like to propose adding Shield, Armor and Shleter to Rcpp. 
For now they live in the tools directory of dplyrRcpp.


Shield
==

That is simplest. When a Shield object is constructed, PROTECT is 
called, when it is destructed UNPROTECT(1) is called. Using it looks 
like this:


ShieldSEXP x( ... ) ;

Shield has a conversion to SEXP operator that returns its SEXP so we can 
pass a ShieldSEXP to any function that takes a SEXP.


Armor
=

This is similar but it uses the less known PROTECT_WITH_INDEX and 
REPROTECT.


It should be preferred to Shield when we change the object we want to 
protect, for example in a loop.


When it is constructed, it protects its SEXP and records its index in 
the protection stack, when something is assigned to it, the new object 
takes its place so the previously protected object might no longer be.


ArmorSEXP x( ... ) ;
x = ... ;


Shelter
===

Shelter is a bit different as it protects several objects in the same 
scope. It has an function call like operator that protects its argument 
and bumps up the number of objects it currently protects. Whe it is 
destructed, it unprotects that many objects.


Looks like this for now:

ShelterSEXP ___ ;
SEXP x = ___(...) ;

There are cases when this is useful and for which I could not use either 
Armor or Shield. They are used throughout dplyrRcpp and it makes perfect 
sense to use them. That's another clear win of C++ against macros.




They are all templated, but it really only makes sense to use SEXP as 
the parameter, maybe I'll enforce that. It just looks nice to me:


ShieldSEXP
ArmorSEXP
ShekterSEXP

It conveys the idea of protecting a SEXP.


I will add them to Rcpp11, and I would like to add them to Rcpp too. So 
I wanted to start a discussion on them here.


With these, we should never need to call PROTECT / UNPROTECT macros ...

Please let me know what you think about that. Getting no reply means 
nobody cares, so please comment on this if you want to see them in Rcpp.


This is starting to be the way I approach contributing to Rcpp, start a 
discussion on a feature and add it if people care. This is somewhat 
different from the approach I used to take which was put the code in 
anyway and let people know afterwards.


This is a non disruptive proposal as the template classes I propose 
don't interract with the rest of the code. We might not use them in 
Rcpp, but we should. There are currently 155 calls to UNPROTECT in the 
.h and .cpp of Rcpp. That is that many macro calls we could get rid of.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] Armor, Shield and Shelter.

[Romain Francois]

Le 11/10/13 13:26, Dirk Eddelbuettel a écrit :


Romain,

On 11 October 2013 at 13:03, Romain Francois wrote:
| Anyway, I'd like to propose adding Shield, Armor and Shleter to Rcpp.

Sure.

| This is a non disruptive proposal as the template classes I propose
| don't interract with the rest of the code. We might not use them in
| Rcpp, but we should. There are currently 155 calls to UNPROTECT in the
| .h and .cpp of Rcpp. That is that many macro calls we could get rid of.

(UN)PROTECT calls in code internal to Rcpp are less of a worry (at least on
the user list);


Sure. I'll make my case in the appropriate channel if we decide to add 
the feature.



another question is how often Rcpp users need to resort to
this in their code, and how often it would help?  I don't have a good idea.


They fit perfectly in what I do with dplyrRcpp. This replaces the usual 
reflex of I can't use an api class so i'll just use PROTECT/UNPROTECT


We can get an idea using some grepping for UNPROTECT in packages that 
depend on Rcpp.



And OTOH as this seems to non-disruptive and orthogonal to existing code, why
not?


It is. That would just be 3 template class, all using inline functions. 
The code produced by the compiler should be equivalent to using 
PROTECT/UNPROTECT ...


The code written by the developper will be nicer.


And the names are very cute indeed. I'd say go for it.

Thanks,  Dirk


Kudos to http://thesaurus.com/browse/protector

I still want to see comments from users.

One thing I'm not certain about is the interface of Shelter, We might be 
able to make something more natural.


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] calling R function triggers tryCatch() ???

[Romain Francois]

I will give some concretes next week. For now, i just wanted to hint: 
- mean is a mammoth. Try applying mean_ : 

mean_ - function(.) .Internal(mean(.))

- by using x(r,_) you are allocating memory at each loop iteration, when we can 
use just one vector, since all rows are by definition of the same size. 

I will contribute code versions of these hints later. 

Romain

Le 11 oct. 2013 à 16:27, Hadley Wickham h.wick...@gmail.com a écrit :

 Interestingly, that shows that rowApply2 is actually slightly _slower_
 than rowApply1.
 
 Hadley
 
 On Fri, Oct 11, 2013 at 9:24 AM, Hadley Wickham h.wick...@gmail.com wrote:
 FYI, I recommend using microbenchmark which uses a much higher
 precision timer so you can see the variability as well as the mean
 times. Also note that you can use /*** R */ to include R code that's
 automatically run when benchmarking:
 https://gist.github.com/hadley/6935459
 
 That gives:
 
 microbenchmark(rowMeans(M),
 +   apply(M, 1L, mean),
 +   rowApply0(M, mean),
 +   rowApply1(M, mean),
 +   rowApply2(M, mean))
 Unit: microseconds
  expr   minlq medianuq   max neval
   rowMeans(M)  5.31  7.11   7.54  7.84  13.9   100
 apply(M, 1L, mean) 46.23 49.46  50.78 53.06 136.9   100
 rowApply0(M, mean) 50.87 53.81  55.36 57.54  85.3   100
 rowApply1(M, mean) 18.92 20.14  21.20 22.44  36.9   100
 rowApply2(M, mean) 18.73 20.18  21.27 22.40  34.0   100
 
 M - matrix(rnorm(1500L), nrow=30L);
 
 microbenchmark(rowMeans(M),
 +   apply(M, 1L, mean),
 +   rowApply0(M, mean),
 +   rowApply1(M, mean),
 +   rowApply2(M, mean))
 Unit: microseconds
  exprmin  lq medianuqmax neval
   rowMeans(M)   9.86  12 13  14.1   21.9   100
 apply(M, 1L, mean) 265.28 288308 349.8  475.2   100
 rowApply0(M, mean) 506.54 541575 604.9 5469.3   100
 rowApply1(M, mean) 174.37 185206 232.4  334.0   100
 rowApply2(M, mean) 171.55 183223 245.8 4244.7   100
 
 On Fri, Oct 4, 2013 at 11:36 AM, Thomas Tse tommy_228_...@yahoo.com.hk 
 wrote:
 The next test compares the speeds:
 
 // [[Rcpp::export]]
 NumericVector rowApply0(NumericMatrix x, const Function FUN)
 {
 int n = x.nrow();
 NumericVector result = no_init(n);
 
 for (int r = 0; r  n; r++) {
   result[r] = asdouble(FUN(x(r, _) ) );
 }
 return result;
 }
 
 // [[Rcpp::export]]
 NumericVector rowApply1(NumericMatrix x, const Function FUN)
 {
 int n = x.nrow();
 NumericVector result = no_init(n);
 
 for (int r = 0; r  n; r++) {
   Language call(FUN, x(r, _)) ;
   result[r] = asdouble(call.fast_eval() );
 }
 return result;
 }
 
 // [[Rcpp::export]]
 NumericVector rowApply2(NumericMatrix x, const Function FUN)
 {
 int n = x.nrow();
 NumericVector result = no_init(n);
 
 Language call(FUN, R_NilValue);
 Language::Proxy proxy(call, 1);
 for (int r = 0; r  n; r++) {
   proxy = x(r, _) ;
   result[r] = asdouble(call.fast_eval() );
 }
 return result;
 }
 
 M - matrix(rnorm(15L), nrow=3L);
 identical(rowMeans(M), apply(M, 1L, mean));
 [1] TRUE
 identical(rowMeans(M), rowApply0(M, mean));
 [1] TRUE
 identical(rowMeans(M), rowApply1(M, mean));
 [1] TRUE
 identical(rowMeans(M), rowApply2(M, mean));
 [1] TRUE
 benchmark(rowMeans(M),
 +   apply(M, 1L, mean),
 +   rowApply0(M, mean),
 +   rowApply1(M, mean),
 +   rowApply2(M, mean),
 +   replications=30L);
   test replications elapsed relative user.self sys.self
 user.child sys.child
 3 rowApply0(M, mean)   30   23.268.551 23.140
 NANA
 2  apply(M, 1, mean)   30   21.307.831 21.130
 NANA
 4 rowApply1(M, mean)   30   10.233.761 10.220
 NANA
 5 rowApply2(M, mean)   309.873.629  9.820
 NANA
 1rowMeans(M)   302.721.000  2.720
 NANA
 
 M - matrix(rnorm(1500L), nrow=30L);
 benchmark(rowMeans(M),
 +   apply(M, 1L, mean),
 +   rowApply0(M, mean),
 +   rowApply1(M, mean),
 +   rowApply2(M, mean),
 +   replications=3L);
   test replications elapsed relative user.self sys.self
 user.child sys.child
 3 rowApply0(M, mean)3   21.32   48.455 21.300
 NANA
 2  apply(M, 1, mean)3   11.17   25.386 11.170
 NANA
 4 rowApply1(M, mean)38.24   18.727  8.190
 NANA
 5 rowApply2(M, mean)38.10   18.409  8.080
 NANA
 1rowMeans(M)30.441.000  0.430
 NANA
 
 M - matrix(rnorm(15L), nrow=300L);
 benchmark(rowMeans(M),
 +   apply(M, 1L, mean),
 +   rowApply0(M, mean),
 +   rowApply1(M, mean),
 +   rowApply2(M, mean),
 +   replications=3000L);
   test replications elapsed relative user.self sys.self
 user.child sys.child
 3 rowApply0(M, mean) 3000   26.65   18.379 26.41 

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 10/10/13 16:51, Dirk Eddelbuettel a écrit :


To bring a bit of closure to this endless thread: It appear from his commit
logs that Romain made the change in his dplyRcpp project we are now supposed
to make per R Core: Demote packages from Depends: to Imports:, and import
what is needed.

That, as best as I can tell, seems to be the way to avoid the clashes seen in
Romain's first email in this thread.

Some more questions re some possible future use below

On 10 October 2013 at 05:15, Romain Francois wrote:
| I don't particularly love macros. I much prefer templates. For example
| in Rcpp11, I replaced thousands lines worth of macros code bloat with a
| few dozens of lines of templates.

Good to see Romain-the-template-whiz clean up after Romain-the-macro-user. :)
And obviously I don't mind all the macros as your use of these macros gives
us all thse awesome features in Rcpp. But macros are a last resort...


Sure. I'm counting 515 macros in Rcpp:

% grep #define **/* * 2 /dev/null | grep -v _h | grep -v _H | wc -l
 515

And only 137 in Rcpp11

% grep #define **/* 2 /dev/null | grep -v _h | grep -v _H | wc -l
 137

Macros are evil for things like this:

#define CONSTANT 42
#define max(x,y) (xy):x?y ;

which can be replaced by const int and inline function. This is 
Effective C++ item #2.


They however can have a role to play in code generation. Here is one 
from Rcpp11:


#define DOT_CALL(name) DotCall(#name, name)

So that one can write:

DOT_CALL(foo)

instead of DotCall(foo, foo)


They are quite useful for debugging too:

#if RCPP_DEBUG_LEVEL  0
#define RCPP_DEBUG( fmt, ... ) Rprintf( %20s:%4d  fmt \n 
, short_file_name(__FILE__), __LINE__, ##__VA_ARGS__ ) ;

#else
#define RCPP_DEBUG( MSG, ... )
#endif

So that we can write:

RCPP_DEBUG( bla bla %d, 42 )

and leave it there when the code is not debugged.


| Would be easy enough to come up with a way to automatically generate
| things automatically.
|
| A package author could leverage tools:::read_symbols_from_object_file,
| i.e. here are all the symbols in Rcpp.so:
|
| symbols - tools:::read_symbols_from_object_file( system.file( libs,
| Rcpp.so, package = Rcpp ) )[,1]
|
| Would be easy to then come up with a naming convention, and generate the
| registration.
|
| read_symbols_from_object_file is why we have been all of a sudden
| forbidden to use functions that R exposes but not part of the api.

Can you (portably, with all (major) compilers and OS choices) pick out
symbols even when they have attribute_hidden set as R does all over its
sources?


No.

But since that sort of thing are typically the task of the package 
maintainer: I don't care.


read_symbols_from_object_file is just a convoluted way to call nm.

 tools:::read_symbols_from_object_file
function (f)
{
if (!nzchar(nm - Sys.which(nm)))
return()
f - file_path_as_absolute(f)
if (!(file.info(f)$size))
return()
s - strsplit(system(sprintf(%s -Pg %s, shQuote(nm), shQuote(f)),
intern = TRUE),  +)
n - length(s)
tab - matrix(, nrow = n, ncol = 4L)
colnames(tab) - c(name, type, value, size)
i - rep.int(seq_len(n), sapply(s, length))
j - unlist(lapply(s, seq_along))
tab[n * (j - 1L) + i] - unlist(s)
tab
}

on windows, there is an equivalent function that does the windows thing.

But again, I don't care. Generating code is the task of the package 
maintainer, so if I want to use something like that, it just has to work 
on whatever I use.


That's similar to calling compileAttributes, or generating the code 
bloat we've put in Rcpp with the generator scripts.


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] [Summary] (Was: question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 10/10/13 17:36, Dirk Eddelbuettel a écrit :


On 10 October 2013 at 17:15, Romain Francois wrote:
| They are quite useful for debugging too:
|
| #if RCPP_DEBUG_LEVEL  0
| #define RCPP_DEBUG( fmt, ... ) Rprintf( %20s:%4d  fmt \n
| , short_file_name(__FILE__), __LINE__, ##__VA_ARGS__ ) ;
| #else
| #define RCPP_DEBUG( MSG, ... )
| #endif
|
| So that we can write:
|
| RCPP_DEBUG( bla bla %d, 42 )
|
| and leave it there when the code is not debugged.

Thanks for all the details and counts on macros. I was mostly aware of this
as you may recall that I wrote a few of those variants in Rcpp too, including
some of the DEBUG ones.


This is not private email. You were rambling about overuse of macros, I 
was just trying to show that :

- sometimes they do something that can't be done
- I'm using less of them in Rcpp11, so I'm definitely concerned about 
macro overuse.



|  Can you (portably, with all (major) compilers and OS choices) pick out
|  symbols even when they have attribute_hidden set as R does all over its
|  sources?
|
| No.
|
| But since that sort of thing are typically the task of the package
| maintainer: I don't care.

I don't follow at all.


Nevermind.


You appeared to be saying you had a solution to the
linking issue, I point out that hidden symbols are still hidden, and you say
it doesn't matter?  How so?


Of course hidden symbols are still hidden. what's the point of hiding 
them if you can see them anyway.


To give some context, I'm taking about using R's linking mechanism. I'm 
talking about generating automatically the code that:

- registers a function with R_RegisterCCallable
- grabs the function with R_GetCCallable

read_symbols_from_object_file gives me the names of all the objects in a 
package .so file, then I can grep around for some pattern and do some 
code generation.


I'm suggesting that as a possible way to not have to write the code by 
hand as you seem to not want to do that.


We don't really need read_symbols_from_object_file for that, we could 
have something like an [[Rcpp::register]] attribute so that when we 
write this in a package .cpp:


// [[Rcpp::register]]
void foo( Bar boom ){
   // whatever
}

Using something like read_symbols_from_object_file would recognize these 
funcions based on their names, that can be:

- using some known pattern, e.g.

void foo__impl()

- the fact that the function is inside some known namespace, e.g.

namespace Export {
void foo() ;
}

The name as given by nm definitely contains namespace information.


| read_symbols_from_object_file is just a convoluted way to call nm.
|
|   tools:::read_symbols_from_object_file
| function (f)
| {
|  if (!nzchar(nm - Sys.which(nm)))
|  return()
|  f - file_path_as_absolute(f)
|  if (!(file.info(f)$size))
|  return()
|  s - strsplit(system(sprintf(%s -Pg %s, shQuote(nm), shQuote(f)),
|  intern = TRUE),  +)
|  n - length(s)
|  tab - matrix(, nrow = n, ncol = 4L)
|  colnames(tab) - c(name, type, value, size)
|  i - rep.int(seq_len(n), sapply(s, length))
|  j - unlist(lapply(s, seq_along))
|  tab[n * (j - 1L) + i] - unlist(s)
|  tab
| }

That is something different from the linking issue we were discussing. This
is a pretty printer for (non-stripped) object code using nm(1).


But not unrelated.


| But again, I don't care. Generating code is the task of the package
| maintainer, so if I want to use something like that, it just has to work
| on whatever I use.

I believe we were talking about two somewhat distinct issues here.

Dirk


I see a connection.

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] [Summary] (Was: question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 10/10/13 18:16, Dirk Eddelbuettel a écrit :


On 10 October 2013 at 18:02, Romain Francois wrote:
| To give some context, I'm taking about using R's linking mechanism. I'm
| talking about generating automatically the code that:
| - registers a function with R_RegisterCCallable
| - grabs the function with R_GetCCallable

[...]

| The name as given by nm definitely contains namespace information.

You are making the heroic assumption that libraries are never stripped, this
is something you have no control.  Eg each of the 100+ r-cran-* packages in
Debian and Ubuntu will by default be stripped, leading to your approach to go
belly-up:

edd@max:~$ nm /usr/lib/R/site-library/tseries/libs/tseries.so
nm: /usr/lib/R/site-library/tseries/libs/tseries.so: no symbols
edd@max:~$

No symbols.

This is a standard distro package a user may have:

edd@max:~$ dpkg -S /usr/lib/R/site-library/tseries/libs/tseries.so
r-cran-tseries: /usr/lib/R/site-library/tseries/libs/tseries.so
edd@max:~$


Thank you for all that detailed information.


So this approach can't be assumed to work _portably across compilers and os
[distros]_ as I asked about earlier -- and which you chose to ignore.


Don't care.


You can look at nm _on your box_ to learn about (unstripped) libraries.  But
I would surmise that you cannot rely on this to build a tool chain.


It appears that either I'm not expressing myself clearly enough, or you 
don't understand what I'm saying or both.


The idea is that for a package foo I'm developping, I want to have a 
mechanism for finding patterned symbols in its so and act upon that 
information to generate some registration code to take advantage of R's 
linking mechanism.


For this I don't care about what symbols are exported in some other 
package in some distribution of some other os. It would just have to 
work for the person developping foo who sometimes has to regenerate the 
registration code.


It looks however that I can easily enough adapt attributes to handle a 
Rcpp::register attribute so that compileAttributes would also generate 
the registration code. So I don't need to use nm anyway.


I'll play with adding a Rcpp::register attribute in Rcpp11 and let you 
know about how I do it. But it does not seem people care about porting 
things I do in Rcpp11 back into Rcpp.


Anyway, as you said earlier, this thread is long enough.

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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] question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 09/10/13 03:41, Dirk Eddelbuettel a écrit :


On 8 October 2013 at 16:53, Dirk Eddelbuettel wrote:
| | This is also what's done in e.g. Rcpp.package.skeleton. However, following 
the
| | new guidelines from CRAN, RcppLdFlags was exported, but not LdFlags. I 
wonder
|
| Darn.  Error on my part.  It should have been LdFlags.  That was the intent.
| Oh well.

Minor correction: Seems we need both. So back to export RcppLdFlags(), but
thanks to Kevin also exporting LdFlags().  Done in svn rev4566.

Dirk


One good thing about the previous system was that other packages could 
follow the same convention and also have a hidden LdFlags function 
giving information about what is required to link against it.


I do it, e.g. on the dplyrRcpp package.

Now that it is exported, I get this when I load dplyrRcpp which is 
annoying:



L'objet suivant est masqué from ‘package:Rcpp’:

LdFlags


What would be the recommendation for such third party packages that also 
ship a library.


Was it really a problem that we called LdFlags with :::, did R CMD check 
look for it in Makevars and Makevars.win ?


It is not really a problem for me, I can eliminate the need for a 
library in dplyrRcpp.


Would it perhaps make sense to think about standard ways for R packages 
to register what they need. We have a system like this for inline 
plugins, maybe it would be interesting to move this up in R and let 
packages communicate in some way (perhaps in DESCRIPTION) what they need.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

___
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