From hin-tak.leung at cimr.cam.ac.uk  Mon Jan  9 18:33:08 2006
From: hin-tak.leung at cimr.cam.ac.uk (Hin-Tak Leung)
Date: Mon, 09 Jan 2006 17:33:08 +0000
Subject: [Rd] R plot display problem under windows when using python rpy
 module.
In-Reply-To: <6ea7b5430601090836k76c9a331t4834bcd5a7a1bbca@mail.gmail.com>
References: <6ea7b5430601090629u6c3a6ed4r41d096e61c2579e7@mail.gmail.com>	
	<43C28618.8060601@cimr.cam.ac.uk>
	<6ea7b5430601090836k76c9a331t4834bcd5a7a1bbca@mail.gmail.com>
Message-ID: <43C29E54.9080505@cimr.cam.ac.uk>

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



[Rd] R plot display problem under windows when using python rpy module.
Hin-Tak Leung