On Sat, Oct 21, 2017 at 2:34 PM, Emmanuel Charpentier <emanuel.charpent...@gmail.com> wrote: > The first one *should* easily use a systemwide R. It probably does not > require the presence of R on a target system to be compiled (but all of this > has to be checked !). > The second one would be difficult to maintain, given asynchronous changes in > R and Sage. The presence of R being no longer guaranteed, it is difficult to > see how it could be compiled without R headers at the very minimum. So this > could only be an optional package. > Furthermore, exploratory work has suggested that completing an rpy2-based > interface was not a trivial task. ITSR that someone (William Stein ?) has > suggested to write a R kernel to be interfaced with Sage the same way > Jupyter does.
Now that I know more about Jupyter kernels, I have learned that they only solve a small (but very interesting) part of the problems that Sage's pexpect interfaces solve. Jupyter kernels solve the following "remote REPL" problem: - send a string to kernel to be evaluated - get back the results of that evaluation as a sequence of JSON-formatted messages, including images (as huge png and svg strings) - control: send interrupt signals, restart etc. The same problem is solved in various ways (usually NOT as good) in each of the pexpect interfaces in Sage. However, the above is just a **tiny part** of the problem that the pexpect interfaces solve. Other problems all involve clever ways of getting nontrivial (and often large) data back and forth between Python and R, Maxima, Singular, Magma, Axiom, etc., and this is highly nontrivial. There's also a lot of interesting code that involves automatically transforming and parsing expression from one system into another. That's where most of the work in our pexpect interface has gone, and where vastly more work could be done. And it's a problem that the Jupyter dev community mostly ignores. Also, with the way we use some of the pexpect interfaces (e.g., the Magma one and the Maxima one at one point), every ms of performance regarding the remote REPL matters a lot. In contrast, the primary use of Jupyter kernels is an interactive web-based UI, for which ms-level performance of the REPL is not even relevant. Thus it's not obvious that restructuring our interfaces to be built on top of Jupyter kernels wouldn't just make our interfaces slower or less robust -- I don't know. Also, in some cases, the Jupyter kernels are really be a Python process using pexpect... Regarding rpy2, it does something fundamentally much more powerful than what Jupyter or our pexpect interfaces do (namely there's only a single process and large data is transferred efficiently). It's hard to use rpy2 though, and for some reason it doesn't seem popular. My impression is that people who want to use python for stats... use python for stats -- statsmodels, pandas, etc, -- all libraries that did NOT exist when rpy2 was created and R and rpy2 were added to Sage. Stats algorithms also tend to be easier to just reimplement than say algorithms in arithmetic geometry (many of which seems to be so deep that they have been implemented only once in human history). Just to reiterate, the state of statistics in the Python ecosystem when I added R to Sage was very different than it is now. -- 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.
