From P.Dalgaard at biostat.ku.dk  Wed Mar 28 17:25:38 2007
From: P.Dalgaard at biostat.ku.dk (Peter Dalgaard)
Date: Wed, 28 Mar 2007 17:25:38 +0200
Subject: [Rd] Bridging R to OpenOffice
In-Reply-To: <200703280648.54111.sdavis2@mail.nih.gov>
References: <Pine.LNX.4.44.0703281210390.31714-100000@reclus.nhh.no>
	<200703280648.54111.sdavis2@mail.nih.gov>
Message-ID: <460A88F2.3080600@biostat.ku.dk>

Sean Davis wrote:
> On Wednesday 28 March 2007 06:25, Roger Bivand wrote:
>   
>> On Wed, 28 Mar 2007, Hin-Tak Leung wrote:
>>     
>>> Hmm, if all you are interested is reading/writing Excel spreadsheets
>>> from R, there are much lighter and easier ways of doing it, than
>>> hooking up with openoffice. The Perl people have had
>>> Spreadsheet::ParseExcel and Spreadsheet::WriteExcel for years (and
>>> they work quite well, personal experience). Those are tiny
>>> (a couple of Mb's?) compared to the size of openoffice.
>>>       
>> I don't think this is the problem here - the proposal says: "Create an
>> add-on component that allows a Calc user to let the R environment do
>> calculations on data from Calc cells and put the results into the
>> spreadsheet again". It feels much more like embedding R in the OO
>> spreadsheet and/or elsewhere, which would be similar to using DCOM in
>> Excel. There would also be questions about how tightly integrated an
>> embedded R should be, how functionality would be provided and documented,
>> and how such a setup ought to be administered and maintained.
>>
>> As RExcel, the structure depends crucially on having joint expertise in
>> place to write and maintain the R script glue (dialogues) to provide the
>> functionality being added to Calc. Typically, this would be something an
>> organisation of some size might need, but it would be unlikely to be a GUI
>> for novice R users unwilling to scale the learning curve (a steep learning
>> curve, of course, means learn a lot in a short time, hence a good thing!).
>>     
>
> There are examples of doing this with Excel, which have been quite successful.  
> Here is at least one example (which I post for potential contact 
> information):
>
> http://linus.nci.nih.gov/BRB-ArrayTools.html
>   
I feel (without much hard evidence to build the feeling on...) that the
main issue is that OOo isn't making it really clear what the preferred
embedding/interfacing methods should be. I did look into the related
issue of database connectivity at some point; toying with the idea of
using oobase or oocalc as a backend for RODBC, but apparently no  ODBC
interface exists. (The other way around is possible: using oobase as a
front end for e.g. mysql via ODBC).

The Windows tools have (D)COM for interfacing to an R server process,
and the corresponding OOo interface is something called UNO, but
step-by-step instructions for using it appear to be hard to come by.

One possible starting point could be to look at the existing language
bindings and see whether they inspire a similar set of R bindings. There
is some experience around with interfacing issues: RSPerl, RPy, RGtk,
the tcltk package, etc. It tends to get somewhat tricky because R's
object model differs from that of OO languages like Java and C++, and is
closer to Lisp's CLOS. Also, if R's property of being a rapid
prototyping language is to be preserved, it is unattractive to blindly
wrap C libraries containing functions of 27 arguments each...

Digging around, I notice that there is an existing "tcluno" package.
This might be made accessible from R's tcltk package.

-- 
   O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907



[Rd] Bridging R to OpenOffice
Peter Dalgaard