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 by folk outside the core.

JN

On 2019-03-04 9:12 a.m., Avraham Adler wrote:
> On Mon, Mar 4, 2019 at 5:01 PM J C Nash <profjcn...@gmail.com 
> <mailto: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 
> <mailto: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

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to