A couple of quick notes ; consistent answer to follow (not soon, alas...) :
Le mardi 1 novembre 2016 03:23:41 UTC+1, William a écrit :
>
> On Mon, Oct 31, 2016 at 6:58 PM, kcrisman <kcri...@gmail.com <javascript:>>
> wrote:
> > All I know is this:
> >
> > 1) We have "sold" a lot of Sage by saying it's all in there, and at
> least
> > some people have used Sage+R effectively. Estimates of how many vary
> > wildly. But non-zero.
>
> Nobody is suggesting deprecating the potential to use Sage+R.
>
That's replacing "It's there" by "It can be done". Not the same thing...
unless you're a theologian or a politician.
The difficulty arises from lateral licensing issues, that apparently forces
us not to ship all that is needed to rebuild "our" R. We could depend on
this couple of libraries as being "part of the operating system" (and
that's Debian and a couple other distros seem to do), but that complicates
the requirements.
A first point is that It seems that a consensus goes to depending on R
instead. More on this later.
A second, different, point is that we can't maintain the current R
interface(s) as standard parts of Sage unless either R is part of Sage or
a strict prerequisite (i. e. Sage won't build without it).
A third point, distinct from the previous two, is that William deems the
current pexpect interface to be insufficient. Having suffered with it, I
tend to concur. But I think that the pexpect() interface is *still* useful.
>
> > 2) rpy2 might be there, but as far as I can tell most people who've used
> > Sage+R use it via the "dumb pexpect interface".
>
> rpy2 is vastly better than anything else when large amounts of data
> need to be shared back and forth between Sage and R. It's the only
> option in that case.
>
Seconded, with one exception. Data *can* be kept and managed on the "Sage"
side and sent to R thought the current pexpect interface (via a suitably
built r.assign call). That loses the R facilities for data management. And
let us stuck with the task of getting back R's results to sage via a
*string*, of all things... It can be done (I've done it, at least in
ad-hoceries), but it's not fun.
>
> > 3) All those thousands of packages are darn useful and can't be easily
> > replaced with pandas or anything else.
>
> This is the same as 1.
>
> > 4) kernels are nice but how do you get Sage command line to do that? I
> > personally would only know how to do it, sort of, in Jupyter notebook,
> and
> > not at all clear how to send stuff back and forth between Sage and R
> there.
> >
>
That's a fourth point, distinct from the three already stated. Having at
least skimmed the documents retrieved by William, I can see his point, at
leans from the systems integrator point of view.
But, IMHO, not what we want to see in Sage.
>
> In SageMathCloud we've been supporting actual users of Sage, R, etc.,
> for a few years now. People frequently request that we install R
> packages. As far as I can tell, 100% of the time they are using R
> directly, via scripts, via %r mode in a notebook (either Sagews or
> Jupyter).
That's because that is the "easy" way to use Sage as a cloud-available R
distribution, which covers a large majority of Sage Cloud users.
Not the same thing as using both R and the rest of Sage, which may be a
less popular exercise, but exists.
> I've never once heard of anybody actually trying to use
> Sage + R yet.
Can you hear me now ?
> As far as I can tell, Sage simply doesn't add anything
> of value that people care or know about when they are using R...
That's probably true of people using SageMath Cloud as a cloud-installed R
distribution. Not what I want to do...
> If
> people are using Python to do stats they use the Python tools; if they
> are using R, then R is already good enough for what they are doing,
> and Sage doesn't add anything.
>
It adds a lot : availability of tools much better at expressing
*structures* than anything available on the R side (thonk graph theory,
symbolic computation, etc...). That's no as popular among applied
statisticians as computing "tests p-values" (the present), but remains the
core problem of statistics ("given some data, what is the "right" structure
that accounts for them ? "., i. e. the future...).
>
> > My conclusion:
> >
> > 1) Definitely don't remove R from Sage, unless we go back on the mission
> > statement.
>
> The mission statement is to create a viable open source alternative to
> Magma, Maple, Mathematica, and Matlab. Not including R in Sage does
> not mean going back on that mission statement.
>
> > We want to be able to easily use all those extra packages with
> > algebra and graph theory. (Not to mention current users.)
>
Don't forget the "engeneering-type" and "undergraduate" users of Sage, who
might not be number theorists, geometers or algebrists, but may finfd in
Sage a *superior* replacement to Mathematica... This "user base" is often
neglected in the discussions in sage-devel. I can think of a few bugs in
elementary algebra/calculus that stand for years after being reported
whithout any attempt to solve them.
>
> > 2) Finding a way to deprecate (!!!) current R behavior is viable, but
> should
> > be a longer-than-normal period. Including graphics and other stuff.
R graphics don't display in the Jupyter notebook. That's why I updated
"our" rpy2 (which does that correctly), this inadvertently creating a mess
: the R instance created by rpy2 is not the same as the one created by
pexpect. And cannot be, as far as I know. A possibility I wasstudying was
to use rpy2's instance for our pexpect interface.
If
> > rpy2 is the answer, great; I recall it being deemed not as satisfactory
> at
> > some point but maybe no one ever tried since pexpect was "good enough".
>
Agreed...
>
> We could remove R from sage-7.5 and the current behavior would likely
> work exactly as is (via pexpect) as long as R is installed somewhere
> on the computer. In fact, things would be better, since all install
> issues involving R itself would be the responsibility of the R
> project.
>
> > 3) Excellent idea to integrate pandas or whatever the current flavor of
> the
> > month is far better!
>
> pandas is not just some "flavor of the month" stats library. It's
> been around since at least 2010, and is a sort of defacto standard at
> this point. There's at least one Oreilly book on it.
>
Hum.. De facto standard for what ?
>From the pandas site
<http://pandas.pydata.org/pandas-docs/stable/overview.html> :
pandas
<http://pandas.pydata.org/pandas-docs/stable/index.html#module-pandas>
consists of the following things
- A set of labeled array data structures, the primary of which are
Series and DataFrame
- Index objects enabling both simple axis indexing and multi-level /
hierarchical axis indexing
- An integrated group by engine for aggregating and transforming data
sets
- Date range generation (date_range) and custom date offsets enabling
the implementation of customized frequencies
- Input/Output tools: loading tabular data from flat files (CSV,
delimited, Excel 2003), and saving and loading pandas objects from the fast
and efficient PyTables/HDF5 format.
- Memory-efficient “sparse” versions of the standard data structures for
storing data that is mostly missing or mostly constant (some fixed value)
- Moving window statistics (rolling mean, rolling standard deviation,
etc.)
- Static and moving window linear and panel regression
<http://en.wikipedia.org/wiki/Panel_data>
An that's all. Data management, a whiff of vanilla descriptive statistics.
Data management is indeed an important (and quite time-consuming) part of
practical applied statistics. But that's not the whole game. Somehow
lacking...
>
> > 4) But if no one is willing/able/whatever to make these new interfaces,
> > keeping pexpect is definitely far better than simply jettisoning R.
>
Agreed 100%
> > (Note e.g. people who have used Sage cell server to embed R graphics in
> web
> > pages - not sure how that would be affected, if it's a separate R
> process or
> > via Sage?)
>
> Andrey would type "apt-get install R" (or whatever) and be done.
>
How do you do that in Cygwin ? And I don't even want to think about Macs...
Now, these remarks do not constitue a structured answer to the two latest
posts. But I need time to think...
HTH,
--
Emmanuel Charpentier
--
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.
