On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier <emanuel.charpent...@gmail.com> wrote: > Dear William, > > thanks for this advice, which I'll consider seriously, notwithstanding its > total opacity to me at the moment.... > > I just checked that the r interface in SMC is indeed different from what > exists in sage "standalone". It is also a bit difficult to understand, due > to present lack of documentation. Cut-n'paste from a sagews : > > help("r") > ︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation > found for 'r'\n\n"}︡{"done":true}︡ > > But the behavior of R in % cells is crystal-clear. The first difficulty I > have is to understand how to exchange data (or other structures) between R > and Sage (which is the *whole* point of the exercise...). > > Do you think that this R interface, specific to Sagemath Cloud, could be > ported to Sage ? And do you think that t would involve R-version specific > code ?
I don't think this question really makes any sense. What you have to do is simply learn Jupyter... then rethink the question. Except that's harder than it should be...! I just posted this to https://gitter.im/jupyter/jupyter: "Hi, I just spent a shockingly large amount of time searching and googling for basically an overview of what a Jupyter kernel is and how to write one. There's some old deprecated docs about this, which all have big pointers to newer docs. I can't find any new docs that simply explain what a Jupyter kernel is and how to write one. I'm trying to convince other Sage developers to use Jupyter kernels instead of the pexpect interfaces I wrote for Sage -- at least for R mode -- and it's impossible to convince them if I can't even point to the docs. So help... For example, going here, I would expect under "Kernels" the docs I want, but I can't find anything." > > Another potential stumbling point it that the main part of the interface > (the IRkernel package), has not (het) been accepted by CRAN, rendering its > future ability questionable. > > I plan to look also at what is offered by the Rpy2 interface It would take a > bit of work to emulate the behavior of the pexpect nterface, but that might > offer a good interim solution (at this time, I have *no* idea about what the > IRkernel and its companion libraries are supposed to do). > > Last recourse : the R library itself. Again, I don't know (yet) what it > offers. > > Again, thank you for your (a bit frightening...) advice, Sorry for being scary. It's just advice. Feel free to ignore, of course. > -- > Emmanuel Charpentier > > Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit : >> >> On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier >> <emanuel.c...@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. -- 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.