On Sunday, October 30, 2016, William Stein <wst...@gmail.com> wrote:
> On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier
> <emanuel.charpent...@gmail.com <javascript:;>> 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."
Answer: https://github.com/jupyter/jupyter/issues/216
>
> >
> > 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 <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 sage-devel+unsubscr...@googlegroups.com <javascript:;>.
> > To post to this group, send email to sage-devel@googlegroups.com
> <javascript:;>.
> > 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)
>
--
Sent from my massive iPhone 6 plus.
--
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.
