similar to: histoRicalg -- project to document older methods used by R and transfer knowledge

It may be worth noting that both Avraham and I are members of the histoRicalg project (https://gitlab.com/nashjc/histoRicalg) that has some modest funding from R-Consortium. The type of concern this nlminb thread raises is why the project was proposed. That is, older codes that may predate IEEE arithmetic and modern programming language processors often were built with a different understanding

Despite my years with R, I didn't know about trace(). Thanks. However, my decades in the minimization and root finding game make me like having a trace that gives some info on the operation, the argument and the current function value. I've usually found glitches are a result of things like >= rather than > in tests etc., and knowing what was done is the quickest way to get there.

On Mon, Mar 4, 2019 at 5:01 PM J C Nash <profjcnash at 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

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

In looking at rootfinding for the histoRicalg project (see gitlab.com/nashjc/histoRicalg), I thought I would check how uniroot() solves some problems. The following short example ff <- function(x){ exp(0.5*x) - 2 } ff(2) ff(1) uniroot(ff, 0, 10) uniroot(ff, c(0, 10), trace=1) uniroot(ff, c(0, 10), trace=TRUE) shows that the trace parameter, as described in the Rd file, does not seem to be

I tend to avoid the the trace/verbose arguments for the various root finders and optimizers and instead use the trace function or otherwise modify the function handed to the operator. You can print or plot the arguments or save them. E.g., > trace(ff, print=FALSE, quote(cat("x=", deparse(x), "\n", sep=""))) [1] "ff" > ff0 <- uniroot(ff, c(0, 10))

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

Hi! I hope you don?t mind me posting this call for participation - I do think the matter at hand is very important for the people on this list, and the people on this list are very important for the matter at hand. For historical reasons, the native API provided by R for use by applications and packages is not as concise and consistent as is could be, and is tied into the internals of the

predict.warn() -- a function to display factor levels in new data for linear model prediction that do not exist in the estimating data. Date: 2005-8-24 From: John C. Nash (with thanks to Uwe Ligges for suggestions) nashjc at uottawa.ca Motivation: In computing predictions from a linear model using factors, it is possible to introduce new factor levels. This was encountered on a practical

How about allowing underscore? (I believe WRE is silent on this, and I have not tried submitting a package with underscore in the title.) As I pointed out in my OP, _optim()_ works. And we have the advantage that we can distinguish package from function. The purpose of consistent editing is surely to provide the affordances that save us from needing extra documentation, as per Donald Norman's

Dear R-devel, We are pleased to inform you that the R Consortium OOP Working Group has been making progress on the S7 (formerly named R7) package and are preparing to submit it to CRAN. The S7 package is a new OOP system designed to be a successor to S3 and S4. As part of that effort, the group has identified a minimal set of narrow changes to base R that would allow S7 to exist as a CRAN

> On 25 Apr 2015, at 13:11 , Prof J C Nash (U30A) <nashjc at uottawa.ca> wrote: > > Hendrik pointed out it was the parentheses that gave the complaint. > Single quotes and no parentheses seem to satisfy R CMD check. Perhaps > that needs to be in the WRE. Well, it is in ?toTitleCase: ...However, unknown technical terms will be capitalized unless they are single

Hendrik pointed out it was the parentheses that gave the complaint. Single quotes and no parentheses seem to satisfy R CMD check. Perhaps that needs to be in the WRE. However, I have for some time used the parentheses to distinguish functions from packages. optim() is a function, optimx a package. Is this something CRAN should be thinking about? I would argue greater benefit to users than title

There will be a meeting of the Ottawa Gatineau R Users Group on Monday November 10 from 4pm to 6pm. More details are provided below. Please pass this message along to friends you think may be interested. Paul Gilbert _________ Dear R friends: To get OGRUG going again I've reserved room DMS 6160 in the Desmarais Building of the University of Ottawa for 1600-1800 November 10. This is the

Apologies if this is posted twice. The r-help mailing system gave an error (reported to moderator) on first try, but it may have gone through. ---------------------------- Original Message ---------------------------- Subject: Re: R-help Digest, Vol 95, Issue 17 From: "Prof. John C Nash" <nashjc at uottawa.ca> Date: Mon, 17 January, 2011 1:04 pm To: r-help at

I appear to have hit one of the "drop" issues raised in some discussions a couple of years ago by Frank Harrell. They don't seem to have been fixed, and I'm under some pressure to get a quick solution for a forecasting task I'm doing. I have been modelling some retail sales data, and the days just after Thanksgiving (US version!) are important. So I created some dummy

On 24.04.2015 22:44, Ben Bolker wrote: > Prof J C Nash (U30A <nashjc <at> uottawa.ca> writes: > >> >> I was preparing a fix for a minor glitch in my optimx package and R CMD >> check gave an error that the title was not in title case. > > [snip] to make Gmane happy ... > >> I have found >> >> A Replacement and Extension of the

Hi R folks, I'd like to announce several new R users groups here in SF, LA, NYC, and Ottawa - as well as their next scheduled event. The goal of these user groups, besides gently explaining 'drop=TRUE' to the uninitiated, is to exchange knowledge, promote best practices, and spur the adoption of R for innovative applications. If I've missed any groups here, please feel to add on

I have tried to compile the working Fortran-90 routines (see attachment) to interface them with R. The compiler automatically caled by R CMD command line prints a bunch of error messages (as follows). I think I'm better off translating the Fortran implementation into R ... which is what I hoped I could avoid. Maura host705:Desktop mauede$ R CMD SHLIB ford.f90 gfortran -arch i386

Hi, I would also be in favor of a stronger stance on licenses. In industry, where we can really get in big trouble for violating a license, we often maintain internal repositories, or need to be careful about filtering what is used from CRAN. I think that is should really be a requirement the package authors commit to stating what the restrictions are on their packages. Nicholas On 10