[Rcpp-devel] Rcpp/C++ serialization of R objects?

[Dirk Eddelbuettel]

Hi Rodney,

On 29 October 2013 at 10:24, Rodney Sparapani wrote:
| Hi Gang:
| 
| I have been through the docs, and if this is answered, then I missed
| it.  Is there a recommended way to serialize an R object with Rcpp?

It's a very good question. 

In the context of my small rhiredis package (a fork / cleanup / demo started
from Wush's initial attempt; both on Github) I poked around the R source but
did not find a good way to access its functionality.  In this case, where we
want to serialize and then push to the (NoSQL) db redis, it turns out that
relying on R's serialize / deserialize is good enough.  You can look there; I
have some simple timing demos there.

| For example, suppose I have created a List in C++ and I want to store
| it with the R equivalent of saveRDS() <because I want to read it in at
| some point later on from within R via readRDS()>.

Yes, I think I would like to have that functionality to some extent.

Now, _for basic C++ types_serialization is of course understood and
implemented so you could just the appropriate, say, Boost library.

For _R_ types I think we will be hard-pressed to do better than R, and at
pain to do it without R. The nestedness of types, attributes, lazy
evaluation, ... all come in.

So your best bet here ... may be to bite the bullet and use an
Rcpp::Function() to just call R on it.
 
Until we convince the Powers That Be to give us an API from C (and hence C++).

| More details if needed...  I am doing some long-running MCMC
| calculations.  And, I would like the C++ code to store the
| results every, say, 10000 iterations.  Of course, I could do
| this in a loop from R.  But, I want to be sure that is really
| necessary before I re-write my R code ;o)

You could call back from C++ to R. If your simulations take 12 hours, you you
waste a few (sub-)seconds to transfer snapshots to R, serialize them and then
dump to disk it shouldn't really matter.  And it would give you a) a security
blanket to fall back on if later parts of the simulation go belly-up and b) a
way to analyse results while the sim is still going.  

I like it.  I am sure other people have ideas too.  

Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com