Following once again two release candidates uploads to GitHub only, a new
release 0.4.400.0 of RcppArmadillo landed on CRAN yesterday.
I wrote a short post about it which you can read here:
http://dirk.eddelbuettel.com/blog/2014/08/19#rcpparmadillo_0.4.400.0
Key points: Armadillo 4.400 with
To create a templated function one can use the macro RCPP_RETURN_VECTOR, e.g:
sourceCpp(code='
#include
template
T index_template ( T X )
{
Rcpp::IntegerVector I(1, 0);
return X[I];
}
// [[Rcpp::export]]
SEXP index ( SEXP X )
{
RCPP_RETURN_VECTOR(index_template, X);
}
')
index(letters)
ind
On 20 August 2014 at 14:30, Sven E. Templer wrote:
| Is there an easier way that I am missing, than to use switch/TYPEOF ...?
No because R is a dynamically-typed language and we will only know at
run-time what you are passing down.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@de
Hi,
I guess RCPP_RETURN_VECTOR could be easily extended to support variadic number
of arguments, using either variadic templates or variadic macros.
https://github.com/RcppCore/Rcpp/blob/3ef9e662d89ebcfe71734675071568302bf10104/inst/include/Rcpp/macros/dispatch.h#L44
RCPP_RETURN_VECTOR is not
Dear all,
during a large simulation study on around 300 cores, I have just noticed
"strange" behavior of my package depending on Rcpp. "Strange" in the sense
that on very rare occasions (around 1 in 10 function calls
through .Call), a NumericMatrix object created at C level and returned back
t
This would be typical gc problems. Could be anywhere.
Even if you run it through gdb, the problem will incubate for some time before
showing symptoms. We’ve been lucky sometimes to fix some of these by accident,
but it is otherwise pretty hard.
Romain
Le 20 août 2014 à 19:38, Gregor Kastner
The general prescription is:
1. Try running the code with `gctortue(TRUE)` on,
2. Try running with a debugger (gdb, lldb, valgrind),
3. Try running with sanitizers (see e.g. Dirk's docker containers:
https://github.com/eddelbuettel/docker-ubuntu-r)
This should help provide you (and/or us) enough
On 20 August 2014 at 10:42, Kevin Ushey wrote:
| The general prescription is:
|
| 1. Try running the code with `gctortue(TRUE)` on,
| 2. Try running with a debugger (gdb, lldb, valgrind),
| 3. Try running with sanitizers (see e.g. Dirk's docker containers: https://
| github.com/eddelbuettel/docke
Thanks to all three of you for your blazing responses.
> | 1. Try running the code with `gctortue(TRUE)` on,
Currently running. Extrapolating from the performance I see now I expect the
bug to reappear in <10 years...
> | 2. Try running with a debugger (gdb, lldb, valgrind),
> | 3. Try running w
On 20 August 2014 at 20:24, Gregor Kastner wrote:
| Thanks to all three of you for your blazing responses.
|
| > | 1. Try running the code with `gctortue(TRUE)` on,
|
| Currently running. Extrapolating from the performance I see now I expect the
| bug to reappear in <10 years...
:)
| > | 2. T
The point of gctorture(TRUE), preferably used with an address-validity
checker like valgrind, is that you are alerted the first time you use
an address that you did not allocate for your use. With
gctorture(FALSE) you are alerted after the n'th bad usage, where n
depends on when the garbage collec
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 ret
12 matches
Mail list logo
