similar to: nlminb - Port library codes

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

> 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

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,

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

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

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

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

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

Not paying close attention to detail, I entered the equivalent of pstr<-c("b1=200", "b2=50", "b3=0.3") when what I wanted was pnum<-c(b1=200, b2=50, b3=0.3) There was a list thread in 2010 that shows how to deal with un-named vectors, but the same lapply solution doesn't seem to work here i.e., pnum<-lapply(pstr, as.numeric) or similar vapply

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

Using R2.12.1 on Ubuntu 10.04.1 I've tried to run the following code chunk in odfWeave <<fig1, echo=TRUE,fig=TRUE,width=7,height=4>>= x<-seq(1:100)/10 y<-sin(cos(x/pi)) imageDefs <- getImageDefs() imageDefs$dispWidth <- 4.5 imageDefs$dispHeight<- 4.5 setImageDefs(imageDefs) X11(type="cairo") plot(x,y) title(main="sin(cos(x/pi))")

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

I'd echo a lot of what has been said about this by the folk who have been making R work so well. One of the main difficulties is that the environment of computations affects relative performance. e.g., what settings did a distro package builder choose. I note that my 3 GHz Dual Core machine running Ubuntu 8.04 gets octave 3.0.0 octave:6> tic; a = a + 1; toc Elapsed time is 0.120027

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

If I run cvec<-c("test.f", "test.sf", "try.g","try.res", "try.f") print(cvec) indx<-grep('\.f',cvec,perl=TRUE) fset<-cvec[indx] print(fset) I get > cvec<-c("test.f", "test.sf", "try.g","try.res", "try.f") > print(cvec) [1] "test.f" "test.sf"

> On 6 Feb 2019, at 10:58, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > ..... > --------------------------------------------------------------------------- > > I summarize what has been reported till: > > Failure in these cases > ======== > 1. Kasper K ("Scientific Linux", self compiled R, using Intel's MKL > for BLAS/LAPACK)

I won't add to the quite long discussion about the vagaries of nlminb, but will note that over a long period of software work in this optimization area I've found a number of programs and packages that do strange things when the objective is a function of a single parameter. Some methods quite explicitly throw an error when n<2. It seems nlminb does not, but that does not mean that

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

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