On 04/03/2019 7:59 a.m., Jim Hester wrote:
Conversely, what is the process to remove a package from core R? It seems
to me some (many?) of the packages included are there more out of
historical accident rather than any technical need to be in the core
distribution. Having them as a core (or recom
I concur with Avraham that capabilities need to be ensured e.g., in recommended
packages. I should have mentioned that. My concern is that the core should be
focused on the programming language aspects. The computational math and some of
the more
intricate data management could better be handled b
On Mon, Mar 4, 2019 at 5:01 PM J C Nash wrote:
> As the original coder (in mid 1970s) of BFGS, CG and Nelder-Mead in
> optim(), I've
> been pushing for some time for their deprecation. They aren't "bad", but
> we have
> better tools, and they are in CRAN packages. Similarly, I believe other
> opt
As the original coder (in mid 1970s) of BFGS, CG and Nelder-Mead in optim(),
I've
been pushing for some time for their deprecation. They aren't "bad", but we have
better tools, and they are in CRAN packages. Similarly, I believe other
optimization
tools in the core (optim::L-BFGS-B, nlm, nlminb)
Conversely, what is the process to remove a package from core R? It seems
to me some (many?) of the packages included are there more out of
historical accident rather than any technical need to be in the core
distribution. Having them as a core (or recommended) package makes them
harder update inde
Hi,
It sometimes happens that some packages get included to R like for example
the parallel package.
I was wondering if there is a process to decide whether or not to include a
package in the core implementation of R?
For example, why not include the Rcpp package, which became for a lot of
user
