similar to: R-help Digest, Vol 95, Issue 17

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

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

> 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

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. It is A Replacement and Extension of the optim() Function R CMD check suggests the incorrect form A Replacement and Extension of the Optim() Function 'Writing R Extensions' suggests single quotes, i.e., A Replacement and Extension of the 'optim()'

This is mainly a reminder to others developing R packages to be careful not to supply control list items that are not used by the called package. Optimx is a wrapper package that aims to provide a common syntax to a number of existing optimization packages. Recently in extending optimx package I inadvertently introduced a new control for optimx which is NOT in any of the wrapped optimization

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

Recently I reported a small bug in optim's SANN method failing to report that it had exceeded the maximum function evaluation limit in the convergence code. This is a small enough matter that I was reluctant to create a full-blown bug report. Indeed in the optimx package Ravi Varadhan and I have been developing on r-forge (under the OptimizeR project) it was a minimal work around to fix

Ravi Varadhan and I have been looking at UCMINF to try to identify why it gives occasional (but not reproducible) errors, seemingly on Windows only. There is some suspicion that its use of DBLEPR for finessing the Fortran WRITE() statements may be to blame. While I can find DBLEPR in Venables and Ripley, it doesn't get much mention after about 2000 in the archives, though it is in the R FAQ

Ravi Varadhan and I have been looking at UCMINF to try to identify why it gives occasional (but not reproducible) errors, seemingly on Windows only. There is some suspicion that its use of DBLEPR for finessing the Fortran WRITE() statements may be to blame. While I can find DBLEPR in Venables and Ripley, it doesn't get much mention after about 2000 in the archives, though it is in the R FAQ

There is also the OptimizeR project on R-forge http://r-forge.r-project.org/R/?group_id=395. Other related projects are there also, but I'll let their authors speak for themselves. Stefan Theussl did a good job in the Task View, but it is from last June, and it would be a monumental effort to keep up to date with all the work going on. We're "almost" ready to put some of our

With some chagrin after spending a couple of hours trying to debug a script, I realized I had typed in something like ans<-optimx(start, myfn, mygr, lower<-lo, upper=up) that is, the "<-" rather than "=". The outcome on my machine was a non-obvious error several layers deep in the call stack. For info, optim() seems to stop much more quickly. The error is

Ben Bolker pointed out in a response about max. likelihood estimation that parameter scaling is not available in nlminb On 02/03/2012 06:00 AM, r-help-request at r-project.org wrote: > * if you were using one of the optimizing methods from optim() (rather > than nlminb), e.g. L-BFGS-B, I would suggest you try using parscale to > rescale the parameters to have approximately equal

This message is about a curious difference in timing between two ways of computing the same function. One uses expm, so is expected to be a bit slower, but "a bit" turned out to be a factor of >1000. The code is below. We would be grateful if anyone can point out any egregious bad practice in our code, or enlighten us on why one approach is so much slower than the other. The problem

I have not included the previous postings because they came out very strangely on my mail reader. However, the question concerned the choice of minimizer for the zeroinfl() function, which apparently allows any of the current 6 methods of optim() for this purpose. The original poster wanted to use Newton-Raphson. Newton-Raphson (or just Newton for simplicity) is commonly thought to be the

I'll not copy all the previous material on this thread to avoid overload. The summary is that all the methods Spencer has tried have some issues. The bad news: This is not uncommon with optimization methods, in part because the problems are "hard", in part because getting them implemented and linked to an interfacing approach like R is very tedious and prone to omissions and

Prof Nash, Prof Galanos Is it possible to use a generic code stub in front of packages that use optimx to improve optimx use or curtail it according to the requirements? Best Regards Amit +91 7899381263 ________________________________________________________________________ Please request Skype as available 5th Year FPM (Ph.D.) in Finance and Accounting Area Indian Institute

Dear R users, I have been trying to understand what the Weights arguments is doing in the estimation of the parameters when using the Surreg function. I looked through the function's code but I am not sure if I got it or not. For example, if I inclue the Surv function in it: survreg(Surv(vector, status)~1,weights=vector2,dist="Weibull") will it try to maximize the likelihood with

This is not about the failure on some platforms, which is an important issue. However, what is below may provide a temporary workaround until the source of the problem is uncovered. FWIW, the problem seems fairly straightforward for most optimizers at my disposal in the R-forge (developmental) version of the optimx package at https://r-forge.r-project.org/projects/optimizer/ I used the code ##

Your function is giving NaN's during the optimization. The R-forge version of optimx() has functionality specifically intended to deal with this. NOTE: the CRAN version does not, and the R-forge version still has some glitches! However, I easily ran the code you supplied by changing optim to optimx in the penultimate line. Here's the final output. KKT condition testing Number of