search for: cxxr

Hello, I am writing an R interface for one of my C++ programs. The computations in C++ are very time consuming (several hours), so the user needs to be able to interrupt them. Currently, the only way I found to do so is calling R_CheckUserInterrupt() frequently. Unfortunately, there are several problems with that: 1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no

Fellipe, CXXR development has moved to github, and we haven't fixed up the build for using git yet. Could you send a pull request with your change to the repo at https://github.com/cxxr-devel/cxxr/? Also, this patch may be useful for pqR too. https://github.com/radfordneal/pqR Thanks On Mon, Jan 19, 2015...

...-------------------- In survival_2.36-12 (and earlier), in the function cox_callback() at cox_Rcallback.c:40: PROTECT(coxlist=eval(lang2(fexpr,data),rho)); the return value of the call to lang2() is vulnerable if allocations within eval() give rise to garbage collection. (Discovered during CXXR development.) Andrew

Hi, I am trying to implement Higham's algorithm for correcting a non positive definite covariance matrix. I found this code in R: http://projects.cs.kent.ac.uk/projects/cxxr/trac/browser/trunk/src/library/Recommended/Matrix/R/nearPD.R?rev=637 I managed to understand most of it, the only line I really don't understand is this one: X <- tcrossprod(Q * rep(d[p], each=nrow(Q)), Q) This line is supposed to calculate the matrix product Q*D*Q^T, Q is an n by m matrix...

On 19/01/2015 4:13 PM, Nathan Kurz wrote: > On Mon, Jan 19, 2015 at 1:00 PM, Felipe Balbi <balbi at kernel.org> wrote: >> I just thought that such a small patch which causes no visible change to >> SVN users and allow for git users to build R would be acceptable, but if >> it isn't, that's fine too. > > Felipe --- > > It would appear that you are

I've been working on an R performance academic project for the last couple years which has involved writing an interpreter for R from scratch and a JIT for R vector operations. With the recent comments on Julia, I thought I'd share some thoughts from my experience since they differ substantially from the common speculation on R performance. I went into the project thinking that R would

...arily generalize. > tl;dr: I (and I think most others) just wish the summary had a more positive outlook for the future of C++ with R. > Well, unless someone actually takes the initiative there is no reason to believe in a bright future of C++. As we have seen with the lack of adoption of CXXR (which I thought was an incredible achievement), not enough people seem to really care about C++. If that is not true, then let's come out of hiding, get together and address it (it seems that this thread is a good start). Cheers, Simon > Best, > Kevin > > On Fri, Mar 29, 2019...

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); 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

...> > >> tl;dr: I (and I think most others) just wish the summary had a more positive outlook for the future of C++ with R. > > Well, unless someone actually takes the initiative there is no reason to believe in a bright future of C++. As we have seen with the lack of adoption of CXXR (which I thought was an incredible achievement), not enough people seem to really care about C++. If that is not true, then let's come out of hiding, get together and address it (it seems that this thread is a good start). > > Cheers, > Simon > > > >> Best, >>...