Thanks a lot for the comment and discussion. A few of mine below.
Bo Peng wrote:
<snipped older inserts>
> The main difference is that rpy does one-way communication, is simpler
> than RSPython, than is easier to use.
>
<snipped older inserts>
>
> I am not an expert on RSPython. I tried RSPython and rpy and chose rpy
> for the following reasons:
>
> 1. rpy is in active maintenance. As you can see from rpy webpage, rpy
> supports all versions of R till 2.2.1, python 2.4 and provides binary
> installers like rpy-0.4.6-R-2.0.0-to-2.2.1-xxxx.xxx . On the contrary,
> a windows installer for RSPython is for R-1.4.0, python 2.2.0.
I think my original comment regarding not-invented-here still applies -
it is a shame that much of the omegahat project is defunc, but it
doesn't mean that somebody interested in a particular orphaned project
can't take it over or fork it or enhance on top. I suspect a small part
of simpler/easier comes from it being smaller and younger, which is
exactly why one should think carefully about the "wheel"...
>
> 2. RSPython uses mainly its RS.call function. This is troublesome and
> is the main reason why I use rpy. For example,
>
> in RSPython:
> RS.call('rnorn', 10)
> in rpy:
> r.rnorm(10)
>
> RSPython does provide similar usage now (maybe after I became a rpy user) but
> RSPython:
> from RS import R
> R.rnorm(10) # works
> R.dev.off() # does not work
Maybe " R.dev("off") " ? Wild-guess here.
>
> Rpy solves this problem by (and the mechanism is clearly described in
> the rpy manual):
> from rpy import *
> r.rnorm(10)
> r.dev_off()
>
> rpy also provides
> r('''arbitrary R piece of code''')
> which is immensely useful to run big trunk of R code.
It might be RS.eval("...")? Again wild-guess here.
The "RS.call('routine', parameter)" syntax is actually how interpreted R
code interacts with compiled C routines in much of R itself.
I think this difference is very much about which language one is more at
home with.
(My background is actually somewhat stronger with Python than R, and
I was trying to learn R's C interfaces by looking at how R
interacts with more familiar languages like Perl/Python/Java)
<snipped>
>
> Exactly. We are doing different things so while you have to use
> RSPython, I have a choice between RSPython and rpy. In my case, all
> the real computations are done in C/C++, wrapped by Python. I could
> have wrapped my C/C++ code in R but R is not good at wrapping C++
> class hierarchy because of the different OOP mechanisms. When I need
> the statistical analysis and plotting capacity of R, I use rpy.
That's correct - C++ together with R is quite painful, and I can imagine
C++/Python being easier. (C++/R I have a little 1st hand experience
with, and I don't for C++/Python).
> As a matter of fact, since Python is a powerful programming language
> than can handle string, text file etc better than R, I usually prepare
> my data in python and pass them to R using rpy.
Thanks. That's useful to know.
HTL
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
