similar to: Title case in DESCRIPTION for package where a word is a function name

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

> 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

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

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

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

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

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)

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

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

I noted Duncan's comment that an answer had been provided, and went to the archives to find his earlier comment, which I am fairly sure I saw a day or two ago. However, neither May nor June archives show Duncan in the thread except for the msg below (edited for space). Possibly tech failures are causing misunderstandings. JN On 14-06-02 06:00 AM, r-devel-request at r-project.org wrote: >

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

There are now several R geographic user groups, and a few have mailing lists on the R mailing list system. Thanks to Martin M, there's also a pointer to a page I'm maintaining to list/describe the groups. The page is at http://macnash.telfer.uottawa.ca/RUG.html Contact me if you have a listing. I'm prepared to wikify it if there is sufficient interest. John Nash

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,

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", >

I spent more time than I should have debugging a script because I wanted x<-seq(0,100)*0.1 but typed x<-seq(O:100)*0.1 seq(0:100) yields 1 to 101, Clearly my own brain to fingers fumble, but possibly one others may want to avoid it. JN

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

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-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