R for the JVM: 60% complete, help wanted!
code.google.com
R for the JVM: 60% complete, help wanted!
1–10 of 19 posts
Re: R for the JVM: 60% complete, help wanted!
#2The primary reason to use R is the large number of stats packages, which are written in a mixture of C, Fortran, and R. I don't see mention of JNI anywhere, but hooking into Fortran and C seem like the most difficult but most essential piece of making this useful.
Re: R for the JVM: 60% complete, help wanted!
#3The primary reason to use R is the large number of stats packages, which are written in a mixture of C, Fortran, and R. I don't see mention of JNI anywhere, but hooking into Fortran and C seem like the most difficult but most essential piece of making this useful.
[deleted]
Re: R for the JVM: 60% complete, help wanted!
#4The primary reason to use R is the large number of stats packages, which are written in a mixture of C, Fortran, and R. I don't see mention of JNI anywhere, but hooking into Fortran and C seem like the most difficult but most essential piece of making this useful.
I agree. The reason I'll drop into R instead of python is often that I need to do some complicated analysis like adaptive multivariate integration over hypercubes (http://cran.r-project.org/web/packages/cubature/index.html) or general maximum pseudolikelihood estimation for multistage stratified, cluster-sampled, unequally weighted survey samples (http://cran.r-project.org/web/packages/survey/index.html).
There are currently > 3500 packages in CRAN, many of which can be found nowhere else. Being able to access java libraries is great, but I an access java libraries from all sorts of different languages. Until it is seamless to install and use these CRAN packages, I'm sticking with the standard interpreter.
Re: R for the JVM: 60% complete, help wanted!
#5The primary reason to use R is the large number of stats packages, which are written in a mixture of C, Fortran, and R. I don't see mention of JNI anywhere, but hooking into Fortran and C seem like the most difficult but most essential piece of making this useful.
I agree. The reason I'll drop into R instead of python is often that I need to do some complicated analysis like adaptive multivariate integration over hypercubes ( http://cran.r-project.org/web/packages/cubature/index.html ) or general maximum pseudolikelihood estimation for multistage stratified, cluster-sampled, unequally weighted survey samples ( http://cran.r-project.org/web/packages/survey/index.html ). There a…
Yeah, there are some killer packages that won't be able to run on Renjin without porting their C sources to java/R. That's a bummer.
But others -- like the survey package -- are pure R and run well on renjin. (Just do library(survey, lib.loc='/path/to/R/library') )
The central goal at this point is to support embedding packages like 'survey' in web apps or larger java apps. If you're looking for a seamless user experience for ad-hoc analysis, we're still quite a ways off!
Re: R for the JVM: 60% complete, help wanted!
#6What about Incanter? It seems like a perfect opportunity to gather two languages trying to do the same thing into a single JVM-focused project.
Re: R for the JVM: 60% complete, help wanted!
#7bedatadriven: R native code is usually slow and always memory hungry. Nonetheless, running R on Google AppEngine is very tempting. Could you give us some idea how the memory usage looks like using Renjin when compared to any other R distribution? Here is example how to measure memory:
http://heuristically.wordpress.com/2010/01/04/r-memory-usage...
Re: R for the JVM: 60% complete, help wanted!
#8Earlier quoted context omitted.
I agree. The reason I'll drop into R instead of python is often that I need to do some complicated analysis like adaptive multivariate integration over hypercubes ( http://cran.r-project.org/web/packages/cubature/index.html ) or general maximum pseudolikelihood estimation for multistage stratified, cluster-sampled, unequally weighted survey samples ( http://cran.r-project.org/web/packages/survey/index.html ). There a…
Yeah, there are some killer packages that won't be able to run on Renjin without porting their C sources to java/R. That's a bummer. But others -- like the survey package -- are pure R and run well on renjin. (Just do library(survey, lib.loc='/path/to/R/library') ) The central goal at this point is to support embedding packages like 'survey' in web apps or larger java apps. If you're looking for a seamless user exper…
Looking at that project page is there a reason you went for an interpreter rather than compiling to JVM byte code directly? Obviously it's a little harder if you're targeting JVMs <v7 as you don't have invokeDynamic to play with, but most of that work will be common to an interpreter or compiler. On the project I'm working on we haven't even implemented an interpreter, the REPL simply compiles to class files that are then loaded to evaluate them.
Re: R for the JVM: 60% complete, help wanted!
#9What about Incanter? It seems like a perfect opportunity to gather two languages trying to do the same thing into a single JVM-focused project.
Incanter is quite nice and I really like Clojure (disclaimer: I am still a beginner), but it has far less libraries than R. I also think the creators of R did a really good job in making seamless the installation of a package (install.packages(...)) and having lots of functions pretty well documented, so a statistician who is not a programmer can easily do his work and quickly come up with results. AFAIK this is still unmatched anywhere else.
Re: R for the JVM: 60% complete, help wanted!
#10[deleted]