On Mon, Mar 4, 2019 at 5:01 PM J C Nash <profjcn...@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.email...@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]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel