Re: Are there any currently major roadblocks on creating/maintaining an interface to R, such as ROctave?

[Nicklas Karlsson]

> Hi,
> 
> I currently have a large package in Octave that has some sizeable
> functionality which depends on R packages. As it is, my octave package
> interfaces the R packages via Octave's *unix *function call (in essence,
> the R package dumps a single final analysis .csv, which is then loaded in
> Octave).
> 
> However, this is not very flexible: Much functionality of the R package is
> left out via functions, for example, which could be used in Octave.
> 
> 1) Trying to find a better way to go about it, I stumbled upon DSC 2003, *10
> Years of Octave - Recent Developments and Plans for the Future. *Section
> 2.2.4 discusses some limitations 17 years ago, but I wonder if they still
> persist (or worsened):
> https://www.r-project.org/conferences/DSC-2003/Proceedings/EatonRawlings.pdf

Encountered Matlab at University first time about 19 years ago, Octave is 
similar and think the basics have stayed the same. Get the impression 
development have slowed down and remember name of mathematicians lived hundred 
years ago, Leibniech, Newton, Jerome Cardan, Karl Pearsson, et. al. mostly dead.

> ROctave: http://www.omegahat.net/ROctave/ (last updated 18 years ago).
> 
> 2) I'd also be interested in knowing if there are any other alternatives to
> just using *unix*. Oct-files appeared a possibility using Cpp to import R,
> and then Octave to Import Cpp, but if I understand it right, it would
> require individually coding each R package function now and in the long
> run.

As I understand R is written in C/C++ and by adding a wrapper it could be 
compiled to an .oct file which could be called from Octave just as any other 
function. This is probably a rather good solution.


Nicklas SB Karlsson