[Rd] Package inclusion in R core implementation

[Avraham Adler]

On Mon, Mar 4, 2019 at 5:01 PM J C Nash <profjcnash using gmail.com> 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
> optimization
> tools in the core (optim::L-BFGS-B, nlm, nlminb) can and should be moved to
> packages (there are already 2 versions at least of LBFGS that I and Matt
> Fidler
> are merging). And optim::SANN does not match any usual expectations of
> users.
>
> I'm sure there are other tools for other tasks that can and should move to
> packages
> to streamline the work of our core team. However, I can understand that
> there is this
> awkward issue of actually doing this. I know I'm willing to help with
> preparing
> "Transition Guide" documentation and scripts, and would be surprised if
> there are
> not others. R already has a policy of full support only for current
> version, so
> hanging on to antique tools (the three codes at the top are based on
> papers all
> of which now qualify for >50 years old) seems inconsistent with other
> messages.
>
> For information: I'm coordinating a project to build understanding of what
> older algorithms are in R as the histoRicalg project. See
> https://gitlab.com/nashjc/histoRicalg. We welcome participation.
>
> Best, JN
>
> On 2019-03-04 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 recommended) package makes them
> > harder update independently to R and makes testing, development and
> > contribution more cumbersome.
> >
> > On Fri, Mar 1, 2019 at 4:35 AM Morgan Morgan <morgan.emailbox using gmail.com>
> > wrote:
> >
> >> 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 the main tool to extend R?
> >>
> >> What is our view on the (not so well known) dotCall64 package which is
> an
> >> interesting alternative for extending R?
> >>
> >> Thank you
> >> Best regards,
> >> Morgan
> >>
>

I have No arguments with updating code to more correct or modern versions,
but I think that as a design decision, base R should have optimization
routines as opposed to it being an external package which conceptually
could be orphaned. Or at least some package gets made recommended and
adopted by R core.

Thank you,

Avi
-- 
Sent from Gmail Mobile

	[[alternative HTML version deleted]]