search

fslaborg / RProvider

Access R packages from F#
http://fslab.org/RProvider/
Other
235 stars 69 forks source link

Improve serialization for RProvider types #163

Open eiriktsarpalis opened 8 years ago

eiriktsarpalis commented 8 years ago

While this really seems to be an rdotnet issue, I thought it appropriate to create an issue here first.

When writing this sample for distributing RProvider code over mbrace, I noticed that many of the types exposed by the API happen to be non-serializable. I understand that most of these define wrapper objects around R values, so making them serializable should be a non-trivial yet workable task.

tpetricek commented 8 years ago

/cc @jmp75 for possible R.NET discussions....

I'm not all that familiar with the internals of R.NET, but I think most of the R.NET values are really just wrappers around native pointers that refer to some value in the R engine (loaded on the current machine).

So making those serializable would be "fun". I suppose what we could do is to secretly convert them to a corresponding .NET value (what the R provider does) such as arrays or Deedle frames and then serialize those...

BTW: That MBrace sample is pretty epic!

eiriktsarpalis commented 8 years ago

@tpetricek Having looked at a couple of class definitions at R.NET, your hypothesis is about right. We could easily make those wrapper classes serializable using the ISerializable interface, which would precisely make those conversions under the hood. But it's really something that must be done in R.NET, as opposed to RProvider.

I like that MBrace sample too, hope it can evolve into a more useful example :)

eiriktsarpalis commented 8 years ago

For the record, here's one rdotnet wrapper type implementation: https://github.com/jmp75/rdotnet/blob/master/R.NET/GenericVector.cs

I think that this could be made serializable. Care must be taken so that deserialization will not fail just because R does not happen to be installed in the recipient machine.

hmansell commented 8 years ago

I think it would be better to serialize the actual values from the R engine. Otherwise you don’t have robust round-tripping. I am pretty sure R has good support for serializing its values – you can save/load workspaces, including all bound values, for example. Even if it doesn’t have the functionality conveniently exposed, SEXP is a reasonably simple and self-describing data structure.

From: Eirik Tsarpalis notifications@github.com<mailto:notifications@github.com> Reply-To: BlueMountainCapital/FSharpRProvider reply@reply.github.com<mailto:reply@reply.github.com> Date: Wednesday, November 25, 2015 at 4:38 AM To: BlueMountainCapital/FSharpRProvider FSharpRProvider@noreply.github.com<mailto:FSharpRProvider@noreply.github.com> Subject: Re: [FSharpRProvider] Improve serialization for RProvider types (#163)

For the record, here's one rdotnet wrapper type implementation: https://github.com/jmp75/rdotnet/blob/master/R.NET/GenericVector.cs

— Reply to this email directly or view it on GitHubhttps://github.com/BlueMountainCapital/FSharpRProvider/issues/163#issuecomment-159550612.

tpetricek commented 8 years ago

Aaah, good idea @hmansell. Quick search reveals this R functions: https://stat.ethz.ch/R-manual/R-devel/library/base/html/serialize.html. This might actually work nicely!

evolvedmicrobe commented 8 years ago

+1 for serializing through calls to R's native save/load functions.