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 ?
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,
--
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
> <[email protected] <javascript:>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
