similar to: control list gotcha

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()'

> 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

In building a function for a package, I'd like to set the defaults in a control list, e.g., makeg<-function(parameters, eps = 1.0e-7, control=list(showwork=TRUE, rubbish=1.0e+101)){ etc. } This does not provide showwork or rubbish within the function if control() is not fully specified. Copying others, I've previously set the control defaults within the function then matched

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

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

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

I've been creating some R tools that manipulate objective functions for optimization. In so doing, I create a character string with R code, and then want to have it in my workspace. Currently -- and this works fine -- I write the code out, then use source() to bring it in again. Example: cstr<-"jack<-function(x){\n cat(\"Silly x:\")\n print(x) \n }\n" write(cstr,

Hi R-friends, Attached is the SAS XPORT file that I have imported into R using following code library(foreign) mydata<-read.xport("C:\\ctf.xpt") print(mydata) I am trying to maximize logL in order to find Maximum Likelihood Estimate (MLE) of 5 parameters (alpha1, beta1, alpha2, beta2, p) using NLM function in R as follows. # Defining Log likelihood - In the function it is noted as

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

x1<-c(5.548,4.896,1.964,3.586,3.824,3.111,3.607,3.557,2.989,18.053,3.773,1.253,2.094,2.726,1.758,5.011,2.455,0.913,0.890,2.468,4.168,4.810,34.319,1.531,1.481,2.239,4.204,3.463,1.727) y<-c(2.590,3.770,1.270,1.445,3.290,0.930,1.600,1.250,3.450,1.096,1.745,1.060,0.890,2.755,1.515,4.770,2.220,0.590,0.530,1.910,4.010,1.745,1.965,2.555,0.770,0.720,1.730,2.860,0.760)

Dear R users When I use OPTIM with BFGS, I've got a significant result without an error message. However, when I use OPTIMX with BFGS( or spg), I've got the following an error message. ---------------------------------------------------------------------------------------------------- > optimx(par=theta0, fn=obj.fy, gr=gr.fy, method="BFGS", >

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

Hi Reuben, I am puzzled to note that the gradient check in "optimx" does not work for you. Can you send me a reproducible example so that I can figure this out? John - I think the best solution for now is to issue a "warning" rather than an error message, when the numerical gradient is not sufficiently close to the user-specified gradient. Best, Ravi.

Dear R users I am trying to use OPTIMX(OPTIM) for nonlinear optimization. There is no error in my code but the results are so weird (see below). When I ran via OPTIM, the results are that Initial values are that theta0 = 0.6 1.6 0.6 1.6 0.7. (In fact true vales are 0.5,1.0,0.8,1.2, 0.6.) -------------------------------------------------------------------------------------------- >

Dear R-users, I'm trying to work out a way to set default values for arguments in a function which includes the optional argument '...'. In practice, I have a 'plot' method for a function which specifies different types of plots. Every different plot should have different default arguments (for example for 'col', 'ylim' etc), plus the argument '...' to

Dear R-er, For a non-linear optimisation, I used optim() with BFGS method but it stopped regularly before to reach a true mimimum. It was not a problem with limit of iterations, just a local minimum. I was able sometimes to reach better minimum using several rounds of optim(). Then I moved to optimx() to do the different optim rounds automatically using "Nelder-Mead" and

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 all, this is my first time, and just begin to use R. But I've a question about optimization using optimx library. It could sound stupid by I'm a bit affraid with the problem, because anything I try, anything Error. The procedure was: optimx(par="10,71,1",fn=(Prey*Provisioning)/Risk, control=list("maximize)) well the problem lies in the initial value parameters, again