similar to: Minor warning about seq

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

> 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

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

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

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,

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

The following example gives output with a line length of 103 on my system. It is causing a nuisance in creating a vignette. Is there something other than e.g., options(width=60) I need to set? The Sweave FAQ suggests this should work. options(width=60) pastured <- data.frame( time=c(9, 14, 21, 28, 42, 57, 63, 70, 79), yield= c(8.93, 10.8, 18.59, 22.33, 39.35, 56.11, 61.73, 64.62,

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

Subject: Non-GPL packages for R Packages that are not licensed in a way that permits re-distribution on CRAN are frequently a source of comment and concern on R-help and other lists. A good example of this problem is the Rdonlp2 package that has caused a lot of annoyance for a number of optimization users in R. They are also an issue for efforts like Dirk Eddelbuettel's cran2deb. There

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 have been successfully been using R on my EEE PC for some while now. Although it uses Xandros I have been able to install various pieces of software by pretending that it was Debian etch. Johannes was kind enough to continue providing binaries on CRAN for a while but I think I am the only person still living in the past as CRAN etch is currently stuck at 2.11.0 and I cannot rely on him to

In order to run some performance tests on optimization tools, I want to be able to avoid the use of swap memory. In *nix systems, at least Linux ones, I can issue a 'sudo swapoff -a' command and use just the RAM available. If I don't do this, at some point swap will be used, the disk goes ballistic and the machine is unresponsive because it is thrashing data to the swap. I

I'll save space and not include previous messages. My 2 cents: At the very least the documentation needs a fix. If it is easy to do, then Ted Harding's suggestion of a switch (default OFF) to check for sign difference would be sensible. I would urge inclusion in the documentation of the +0, -0 example(s) if there is NOT a way in R to distinguish these. There are occasions where it is

I'm planning to try to use Mike Powell's new BOBYQA optimization routine to see if it is a good candidate to eventually replace Nelder-Mead as the optim() default. (Don't panic -- this won't happen quickly.) Mike writes f77 code. After some chasing about, I've realized that because optimization codes need to call the objective function written in R, they need to use a language

Having looked at documentation and codes, I'm still looking to find out who did the installation of the Port libraries. As I work on optimization code improvements, there are often choices of settings (tolerances etc.), and I'd prefer to learn if there are particular reasons for choices before diving in and making any adjustments. It is also worth giving credit where it is due. Given

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

I'm inclined to agree with the view that the "precision" of a generator should be highlighted better in the manual pages. When I do ?runif I don't see a mention, but ?.Random.seed DOES give the info, as Duncan points out, and it is suggested to look there. A 1-liner with each random number generator "CAUTION: random number generators use different mechanisms and

dhabby wrote: Last week I run in to a lot a problems triyng to fit an ARIMA model to a time series. The problem is that the internal process of the arima function call function "optim" to estimate the model parameters, so far so good... but my data presents a problem with the default method "BFGS" of the optim function, the output error looks like this: