similar to: BLAS benchmarks on R 2.12.0 and related performance issues

Hi, I saw on the mailing list and in the NEWS file that some unsafe math transformations were disabled for the reference BLAS implementation that is used in R. We have a set of performance tests for the OpenMx library, and some of the tests have a x3-10 slowdown in R 2.12.0 versus 2.11.1. When I copy the shared library libRblas.0.dylib from the 2.11.1 installation into the 2.12.0 installation,

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

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

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

I've been updating the information on tuned BLAS for R-admin in R-patched and R-devel. We have ATLAS (widely available, including for Windows) MKL (licensed on ix86 and x86_64 Linux and Windows) ACML (by AMD, but for all ix86 and x86_64 chips, Linux and Windows. Now available for gfortran.) Goto (academic use only, only some chips, only Linux) MKL and ACML provide full LAPACK,

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

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

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

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

Apologies if this is posted twice. The r-help mailing system gave an error (reported to moderator) on first try, but it may have gone through. ---------------------------- Original Message ---------------------------- Subject: Re: R-help Digest, Vol 95, Issue 17 From: "Prof. John C Nash" <nashjc at uottawa.ca> Date: Mon, 17 January, 2011 1:04 pm To: r-help at

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

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

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