Still didn't get the point, or missed the topic ? It's OpenOffice.org and R not Excel and R, two totally different products at least from a philosophical standpoint. Not everybody is willing to pay license fee for Excel to be able to use R via a GUI. That's how the idea was born to integrate or bridge R with OpenOffice.org Calc Access statistical data analysis functionality computed by the almighty R engine from menues in Calc, and getting the results back in Calc (more for users than for developers). A plugin could do the job. There is no point in saying "there is something in Excel" like there is none in saying "Why not using "S" ? You may want to follow the link, offered by Leonard, to the "Google Summer of Code"-project which is menthored by Sun Microsystems (Star/OpenOffice developers), to get a clearer picture about it. http://wiki.services.openoffice.org/wiki/Summer_of_Code_2007#Integration_of_R_into_Calc
best regards Stefan Sean Davis said the following on 28.03.2007 12:48: > 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 > > Sean > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- "Just because the message may never be received does not mean it is not worth sending." ******************************************************************* Stefan Zimmermann Tel/Fax: +49 40 23646 - 645/950 Six Sigma Black Belt, StarOffice mailto:[EMAIL PROTECTED] Sun Microsystems GmbH http://www.sun.com/staroffice Nagelsweg 55, D-20097 Hamburg mobile: +49 172 87 57 504 ******************************************************************* Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel