-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Rcpp::as< arma::Cube<T> > #63
Comments
That is awesome. I meant to follow-up on the StackOverflow question suggesting exactly that. Conrad is playing things old-school so we cannot ping him just by GitHub handle. I will send him an email. Back in the real world, I am not sure we really need much besides the Now, you are of course more rigorous than my thinking-out-loud here so I with that 👍 for the two-step conversion which is clearly better than not having any. And remember: we cannot get from I'll try to take a closer look. |
By the way, Conrad did toss a pre-release of Armadillo 6.300 at me which I'll put through a full reverse-depends check. If you prepare a PR I could merge it into that test branch too... This is probably going to be fairly orthogonal and only touch "our" files. But no rush -- we can also deal with this in a few days. |
That sounds great Dirk. I also was thinking that people are much less inclined to reach for |
👍 |
I guess we forgot a Thanks again! |
I took a shot at implementing a means of converting
Rcpp::Vector
s toarma::Cube
s, but wanted to get some feedback on my code before submitting a PR because I think there are some minor sticking points worth discussing. The full change is reflected in RcppArmadilloAs.h on my fork, in the form ofRcpp::Exporter< arma::Cube<T> >
; andExporter
specializations, one for each ofarma::fcube
,arma::ucube
, andarma::cx_fcube
The first specialization works for fine for the
Cube<double>
,Cube<sword>
, andCube<cx_double>
, but was choking on the remaining three typedefs. I could not come up with an elegant approach to encapsulate everything in one template, so I ended up with the additional three specializations that "piggy back" on their counterparts which do compile; e.g. to get anarma::Cube<float>
/arma::fcube
, aSEXP
is first converted to anarma::cube
using (1), and then converted to anarma::fcube
using Armadillo'sconv_to< >::from
utility. Presumably this adds additional overhead which is not ideal, but as stated, I was unable to avoid this extra step. I am certainly open to any alternative suggestions however.In my unit test file (using the C++ functions here), two of the tests involving
arma::cx_fcube
s use a modified tolerance value of1.5e-7
when compared to base R's equivalent calculation. I suspect this has to do with a loss of precision in the conversion fromdouble
tofloat
, but regardless I wanted to call attention to this.Finally, my
Exporter
specialization is written such that an exception will be thrown if the input object to be converted does not have exactly three dimensions. Is this desirable?Taking into account everything above, the corresponding Travis build was successful, but I certainly some discussion is in order.
The text was updated successfully, but these errors were encountered: