Re: [Rd] Use of C++ in Packages
It's great to see the community mobilize to try to resolve this issue. Obviously C++ has become a big part of R extensions, so it would be nice to have clear guidelines and tools to be able to use C++ safely with the R API. Unfortunately doing this will probably require a fair bit of work. If R-core where to do this it would take away from other valuable improvements they could be making on R itself. Given there is already a supported and documented extension mechanism with access to the R API via C, I can see why R-core might be reluctant to divert resources from R development to add the same level of support for C++. Obviously it would be impossible to try to provide better documentation and/or mechanisms for C++ extensions without some R-core involvement, but it seems like much of the grunt work could be done by others. I unfortunately have no C++ experience so cannot help here, but hopefully there are others that have the experience and the recognition in the community to offer to help and have their offer accepted. Perhaps R-consortium can even fund, although given the level of expertise required here the funding may need to be meaningful. That seems like the natural step here. Someone with the qualifications to do so either volunteers or is funded to do this, and hopefully R-core agrees to provide input and final stamp of approval. The documentation is probably more straightforward, as tools will need more work from R-core to integrate. It is possible R-core may decline to do this, but absent someone actually offering to put in the hard work it's all theoretical. Respectfully, Brodie. On 3/30/19 3:59 AM, Romain Francois wrote: tl;dr: we need better C++ tools and documentation. We collectively know more now with the rise of tools like rchk and improved documentation such as Tomas’s post. That’s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. I think it is important to not equate C++ as a language, and Rcpp. Also, C++ is not just RAII. RAII is an important part of how Rcpp was conceived for sure, but it’s not the only thing C++ can bring as a language. Templates, lambdas, the stl are examples of things that can be used for expressiveness when just accessing data without interfering with R, calling R api functions ... It would be nice that the usual « you should do that only if you know what you’re doing » be transformed to precise documentation, and maybe become part of some better tool. If precautions have to be taken before calling such and such functions: that’s ok. What are they ? Can we embed that in some tool. It is easy enough to enscope code that uses potentially jumpy code into a c++ lambda. This could be together with recommendations such as the body of the lambda shall only use POC data structures. This is similar to precautions you’d take when writing concurrent code. Romain Le 30 mars 2019 à 00:58, Simon Urbanek a écrit : Kevin, On Mar 29, 2019, at 17:01, Kevin Ushey wrote: I think it's also worth saying that some of these issues affect C code as well; e.g. this is not safe: FILE* f = fopen(...); Rf_eval(...); fclose(f); I fully agree, but developers using C are well aware of the necessity of handling lifespan of objects explicitly, so at least there are no surprises. whereas the C++ equivalent would likely handle closing of the file in the destructor. In other words, I think many users just may not be cognizant of the fact that most R APIs can longjmp, and what that implies for cleanup of allocated resources. R_alloc() may help solve the issue specifically for memory allocations, but for any library interface that has a 'open' and 'close' step, the same sort of issue will arise. Well, I hope that anyone writing native code in package is well aware of that and will use an external pointer with finalizer to clean up native objects in any 3rd party library that are created during the call. What I believe we should do, and what Rcpp has made steps towards, is make it possible to interact with some subset of the R API safely from C++ contexts. This has always been possible with e.g. R_ToplevelExec() and R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). In theory, as a prototype, an R package could provide a 'safe' C++ interface to the R API using R_UnwindProtect() and friends as appropriate, and client packages could import and link to that package to gain access to the interface. Code generators (as Rcpp Attributes does) can handle some of the pain in these interfaces, so that users are mostly insulated from the nitty gritty details. I agree that we should strive to provide tools that make it safer, but note that it still requires participation of the users - they have to use such facilities or else they hit the same problem. So we can only fix this for the future, but
Re: [Rd] [External] re: default for 'signif.stars'
Abs, There are definitely problems with the editorial, but I think "most mega-ultra-super-biased" is an overreaction. It appears that you have overlooked some of the points made there, and the fact that it does not pretend to be an exhaustive list of alternative methods. The editorial attempts to digest what is in 43 articles in that special issue. Some of those articles do promote Bayesian methods – not a surprise – and some advocate using P values but without ascribing magical properties to P < 0.05. My own emmeans package does present P values (sans stars, or emojis either) in a lot of contexts. More to the point, the criticisms you offer have to do with later sections of the editorial – not the initial part, which is largely a repeat of an earlier ASA statement on interpretation of P values with the added recommendation that people should never say "statistically significant." It is that initial part that I think does describe a consensus of a large and growing proportion of statisticians and other scientists that placing undue emphasis on "statistical significance" is a bad thing. Emphasizing P values by adding stars encourages that kind of misdirected emphasis. It seems fairly harmless to change the default for "show.signif.stars" to FALSE. However, I do recognize that no change to R's defaults should be taken lightly or done without careful consideration. I only ask that such careful consideration take place, and hope in fact that a plan can be made to phase-in such a change. Thanks, Russ Russell V. Lenth - Professor Emeritus Department of Statistics and Actuarial Science The University of Iowa - Iowa City, IA 52242 USA Voice (319)335-0712 (Dept. office) - FAX (319)335-3017 From: Abs Spurdle Sent: Thursday, March 28, 2019 12:19 AM To: Lenth, Russell V ; r-devel Subject: [External] re: [Rd] default for 'signif.stars' I read through the editorial. This is the one of the most mega-ultra-super-biased articles I've ever read. e.g. The authors encourage Baysian methods, and literally encourage subjective approaches. However, there's only one reference to robust methods and one reference to nonparametric methods, both of which are labelled as purely exploratory methods, which I regard as extremely offensive. And there don't appear to be any references to semiparameric methods, or machine learning. Surprisingly, they encourage multiple testing, however, don't mention the multiple comparison problem. Something I can't understand at all. So, maybe we should replace signif.stars with emoji...? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of C++ in Packages
Hi, It may or may not be of interest to you but an example how to access R functions from C++ can be found in the ROOT C++ framework, ROOT Version 6, see e.g.: https://root.cern/doc/master/classROOT_1_1R_1_1TRInterface.html with an example shown in: https://root.cern/doc/master/r_2example_8C.html BTW, I strongly disagree that C++ does not have a bright future! Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ P.S.: Accessing a complete C++ program (based on ROOT Version 5) from R is shown in my Bioconductor package 'xps' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of C++ in Packages
tl;dr: we need better C++ tools and documentation. We collectively know more now with the rise of tools like rchk and improved documentation such as Tomas’s post. That’s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. I think it is important to not equate C++ as a language, and Rcpp. Also, C++ is not just RAII. RAII is an important part of how Rcpp was conceived for sure, but it’s not the only thing C++ can bring as a language. Templates, lambdas, the stl are examples of things that can be used for expressiveness when just accessing data without interfering with R, calling R api functions ... It would be nice that the usual « you should do that only if you know what you’re doing » be transformed to precise documentation, and maybe become part of some better tool. If precautions have to be taken before calling such and such functions: that’s ok. What are they ? Can we embed that in some tool. It is easy enough to enscope code that uses potentially jumpy code into a c++ lambda. This could be together with recommendations such as the body of the lambda shall only use POC data structures. This is similar to precautions you’d take when writing concurrent code. Romain > Le 30 mars 2019 à 00:58, Simon Urbanek a écrit : > > Kevin, > > >> On Mar 29, 2019, at 17:01, Kevin Ushey wrote: >> >> I think it's also worth saying that some of these issues affect C code >> as well; e.g. this is not safe: >> >> FILE* f = fopen(...); >> Rf_eval(...); >> fclose(f); > > I fully agree, but developers using C are well aware of the necessity of > handling lifespan of objects explicitly, so at least there are no surprises. > > >> whereas the C++ equivalent would likely handle closing of the file in the >> destructor. In other words, I think many users just may not be cognizant of >> the fact that most R APIs can longjmp, and what that implies for cleanup of >> allocated resources. R_alloc() may help solve the issue specifically for >> memory allocations, but for any library interface that has a 'open' and >> 'close' step, the same sort of issue will arise. > > Well, I hope that anyone writing native code in package is well aware of that > and will use an external pointer with finalizer to clean up native objects in > any 3rd party library that are created during the call. > > >> What I believe we should do, and what Rcpp has made steps towards, is make >> it possible to interact with some subset of the R API safely from C++ >> contexts. This has always been possible with e.g. R_ToplevelExec() and >> R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). >> In theory, as a prototype, an R package could provide a 'safe' C++ interface >> to the R API using R_UnwindProtect() and friends as appropriate, and client >> packages could import and link to that package to gain access to the >> interface. Code generators (as Rcpp Attributes does) can handle some of the >> pain in these interfaces, so that users are mostly insulated from the nitty >> gritty details. > > I agree that we should strive to provide tools that make it safer, but note > that it still requires participation of the users - they have to use such > facilities or else they hit the same problem. So we can only fix this for the > future, but let's start now. > > >> I agree that the content of Tomas's post is very helpful, especially since I >> expect many R programmers who dip their toes into the C++ world are not >> aware of the caveats of talking to R from C++. However, I don't think it's >> helpful to recommend "don't use C++"; rather, I believe the question should >> be, "what can we do to make it possible to easily and safely interact with R >> from C++?". Because, as I understand it, all of the problems raised are >> solvable: either through a well-defined C++ interface, or through better >> education. > > I think the recommendation would be different if such tools existed, but they > don't. It was based on the current reality which is not so rosy. Apparently > the post had its effect of mobilizing C++ proponents to do something about > it, which is great, because if this leads to some solution, the > recommendation in the future may change to "use C++ using tools XYZ". > > >> I'll add my own opinion: writing correct C code is an incredibly difficult >> task. C++, while obviously not perfect, makes things substantially easier >> with tools like RAII, the STL, smart pointers, and so on. And I strongly >> believe that C++ (with Rcpp) is still a better choice than C for new users >> who want to interface with R from compiled code. > > My take is that Rcpp makes the interface *look* easier, but you still have to > understand more about the R API that you think. Hence it much easier to write > buggy code. Personally, that's why I don't like it (apart from the code > bloat),