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.

Reply via email to