On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier <emanuel.charpent...@gmail.com> wrote: > OK. It seems that a clear consensus exists for the excision of R _proprio > dictu_ from Sage. > > If we break it, can we at least keep the (Sage's) pieces ? An optional > package offering the current R interface(s) depending on a systemwide(at > least user-reachable) version of R and the R library might offer the > functionality without entailing the (not so trivial) work of maintaining our > own R port. > > Do you have an idea of the amount of work involved ? And how to, do it ? The > rpy2 part is probably easy, but I expect surprises on the pexpec(t) front > (at least if we want to keep compatibility with existing code using current > R interface facilities...). Any hint on the right starting point(s) would > be welcome... > > BTW : I have also had a (quite superficial) look at what pandas and > statsmodel claim to do. They (and scikit-learn, which look interesting, and > stan, already available from Python) might be indeed useful for > run-of-the-mill descriptive analysis and regression models (and Stan for > more exotic modeling). Packaging them for Sage might prove useful. > > However, those 9000+ R packages are here for a reason : if some of them (a > small minority, IMHO) are obvious PhD-earning byproducts, others aim to > solve difficult (if specialized) problems, badly solved (or not even > considered) by the aforementioned trio. keeping a way to reach them from > Sage might be important. Hence my plea for an "R interface(s)" package. > > Another (IMHO futile) reason for keeping an R interface in our arsenal is > "name recognition" : quoting R in a "Materials and methods" section no > longer raises questions from reviewers ; somehow, I doubt that pandas and > statmodels get the same answer... > > What can you add ? Can someone propose a work plan ?
I'm not thinking about politics and name recognition below - I'm just providing a technical/engineering perspective. If anybody is seriously planning to work on the R pexpect interface, I would personally suggest they consider instead working on the R Jupyter kernel bridge instead, and maybe create a drop in replacement for the current pexpect interface that uses the R Jupyter kernel. This would likely be time well spent. This is what we (mostly Hal Snyder) have been doing with SageMathCloud, where now the %r mode in Sage worksheets is implemented entirely using Jupyter (which we did due to user bug/robustness reports with the sage pexpect interface): https://github.com/sagemathinc/smc/blob/master/src/smc_sagews/smc_sagews/sage_jupyter.py Some history - I wrote those (stupid) pexpect interfaces in 2005-2006 as a way to bootstrap making Python talk to everything else. However, they are basically the worst *viable* approach to the problem. Jupyter kernels are potentially a lot more work than using pexpect, but they are clearly a better approach. Yes, using pexpect is one way to write a Jupyter kernel, but fortunately there are better ways. For example, the Jupyter kernel is 1000(s) of lines of nontrivial code written in the R language, which is being improved all the time due to extensive use by users. The Jupyter R kernel is a serious actively developed project: https://github.com/IRkernel/IRkernel Compare that to the Sage R pexpect interface... https://github.com/sagemath/sage/commits/master/src/sage/interfaces/r.py -- William -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
