similar to: Character string to R object

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

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

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

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

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

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

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

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

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"

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

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

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)

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: