0

I'm currently working on an R package that uses Rcpp and RcppArmadillo and I have encountered a strange error that happens randomly. I can't post all the code of my functions to reproduce it from the scratch (it's 400 + 300 lines), but you can find the package on github: https://github.com/config-i1/CES - the function I use is in the "R/ces.R" file and it depends on the functions in "src/cesfun.cpp".

So when you install the package (devtools::install_github("config-i1/CES")) and run the following commands:

library('Mcomp')
x <- cbind(c(rep(0,25),1,rep(0,43)),c(rep(0,10),1,rep(0,58)))
ces(ts(c(M3$N1457$x,M3$N1457$xx),frequency=12),h=18,holdout=T,intervals=T,seasonality="F",xreg=x,trace=T)->test

the error Error: not compatible with requested type is sometimes returned. But this doesn't happen all the time (approximately 1 time out of 3 runs), so it is hard to trace this error. This thing happens on both Linux and Windows. And R just crashes on Mac OS instead of showing the error.

I actually have tried to conduct an investigation and found out that the error happens at random iteration in a for loop when the following Rcpp function is called...

code skipped

I know that I've probably done something wrong but I can't figure out what.

I would appreciate any help on this!

Thank you!

UPDATE.

I found what was the error in the code. So just in case someone encounters something similar, here's what was the problem and how to solve it:

I used one and the same function that was called both from R and Rcpp in different parts of the code. So the variables were defined as SEXP: forecaster(SEXP matxt, SEXP matF). As the result when I called the function in Rcpp I needed to use wrap() to transform arma:mat variables into SEXP. The call was something like: forecaster(wrap(matrixxt),wrap(matrixF)).

In the majority of cases this worked perfectly well but sometimes for some reason wrap() function was not doing what it was supposed to do and as the result something completely different was passed to forecaster. The passed value in its' turn could not be transformed into NumericMatrix in forecaster, thus the "Error: not compatible with requested type". This happened rarely and was hard to trace.

The solution was to change forecaster arguments to the needed types: forecaster(arma::mat matrixxt, arma::mat matrixF), - pass the values to forecaster in Rcpp directly, without the wrap(), and write a special Rcpp wrapper function (so the forecaster could be called from R).

Ivan Svetunkov
  • 21
  • 1
  • 4

1 Answers1

3

Welcome to StackOverflow. Have a look around, and get a feeling for what questions are helpful and which ones aren't.

Yours is (at current) not helpful as too broad---you simply have a bug in your code where every once in a while you supply a non-matching type. Rcpp has become moderately successful with over 450 packages on CRAN using it and now 150 of those using RcppArmadillo. These types of objects have hence been instantiated millions of times and represent robust code -- so you should try to reduce your problem down further and further until you have the smallest possible reproducible example.

Community
  • 1
  • 1
Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • Thank you for the warm welcome! I've read a lot of threads about Rcpp but unfortunately could not find any explanation of what "not compatible with requested type" means. I finally figured out what was the problem - see the update in the question. I will try not to ask stupid questions in the future :). Thanks! – Ivan Svetunkov Sep 04 '15 at 17:16
  • 1
    The other likely issue is that you weren't protecting the `SEXP` objects passed in from the garbage collector. Once you generate a `SEXP` object with `wrap()`, the onus of protection now lies on you (whereas, with Rcpp classes, protection of the underyling R data is handled on object construction / destruction) – Kevin Ushey Sep 04 '15 at 17:37
  • Thank you Kevin! This actually makes sense and explains "random" behaviour. Is there a way to protect `SEXP` object? What should be used? – Ivan Svetunkov Sep 04 '15 at 17:40