On Fri, Jan 6, 2012 at 12:39 PM, John Chambers <j...@stat.stanford.edu> wrote: > At the risk of derailing this thread into the quicksand of programming style > .... > > Except when required by the specific application, my preference would be to > stay with the Rcpp idiom. Mixing in the older C API seems to risk more > programming error. Of course, each application is different and we have to > make decisions about efficiency (machine) vs possible inefficiency (human).
I would argue that special-purpose functions and macros for handling the funky C structures are the best way of handling the funky C structures. Relative to working with C++ classes and methods they are clunky but, short of converting to something like CXXR, we are stuck with the C structures. > The "Rf_" part of the API in particular is ugly and somewhat of an add-on > forced in a few examples by the use of some common names in the macro files. But, as it stands, that is a requirement when using Rcpp. I think of the Rf_ part as more due to the fact that C doesn't have a concept of namespaces so anything in the R API is at the top level namespace leading to some conflicts. > This year in our Stanford grad course, I'm planning to push Rcpp, so in a > few months I may have a different view. :-) > > Cheers, > John > > > On 1/6/12 10:15 AM, Dirk Eddelbuettel wrote: >> >> On 6 January 2012 at 13:00, Steve Lianoglou wrote: >> | Hi, >> | >> | 2012/1/6 Douglas Bates<ba...@stat.wisc.edu>: >> | [snip] >> |> As I mentioned in another thread, I prefer the idiom >> |> >> |> int n2 = ::Rf_asInteger(n); >> |> >> |> because asInteger is part of the R API (in Rcpp it must be called as >> |> Rf_asInteger - the :: is a hint to the compiler that it will be found >> |> in the global namespace). Functions like asInteger and asReal are >> |> used in thousands of places in the base R code and have been optimized >> |> to death as well as being as general as they can possibly be. >> | >> | Cool ... I actually missed that tip, thanks for pointing it out again. >> >> And if one overcomes the "ick" factor of mixing APIs<grin>, it saves a >> little: >> >> R> library(inline) >> R> library(microbenchmark) >> R> >> R> fr<- cxxfunction(signature(xs="integer"), plugin="Rcpp", body=' >> + int x = ::Rf_asInteger(xs); >> + return Rcpp::wrap(x); >> + ') >> R> >> R> frcpp<- cxxfunction(signature(xs="integer"), plugin="Rcpp", body=' >> + int x = Rcpp::as<int>(xs); >> + return Rcpp::wrap(x); >> + ') >> R> >> R> microbenchmark(fr(123), frcpp(123)) >> Unit: nanoseconds >> expr min lq median uq max >> 1 fr(123) 841 878.5 908.5 976 15684 >> 2 frcpp(123) 976 999.5 1017.0 1085 6589 >> R> >> >> A good chunk here is "fixed" cost of calling a function, returning a >> value, ... so that the "variable" gain of ::Rf_asInteger() looks pretty >> good. >> >> Dirk, somewhat wondering why we're debating 100ns gains in the context of >> R >> > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel