Interesting. No matter what I do here, I can't seem to get the test to fail using R's BLAS with clean 32 bit builds. So perhaps it is not just the BLAS, but a combination of R's BLAS and specific hardware?, which gets me into a realm of knowledge below the event horizon.
Have there been any repeatable scenarios where vecLib can be used without failure on a particular Mac platform? Also, I just noted Simon's reply to a different thread on r-sig-mac to Stefan Evert, in which he notes that there may be a change in the default BLAS for OSX to vecLib in the next R release. Of course, now given Prof. Ripley's observations, it will be interesting to see the actual impact in the wild. Thanks, Marc On Oct 21, 2010, at 11:23 AM, Prof Brian Ripley wrote: > Let me point out > https://stat.ethz.ch/pipermail/r-sig-mac/2010-July/007608.html > > This is not just a BLAS issue: I saw it with both vecLib and the reference > BLAS. > > The lme4 code is doing exactly the same calculation for M2. and M2, but > sometimes when it does that calculation the first time in a session it gives > a different answer. That makes it really hard to get a handle on, and easy > to suppose one has a fix (been there a few times myself). > > > On Thu, 21 Oct 2010, Marc Schwartz wrote: > >> >> On Oct 21, 2010, at 8:47 AM, Federico Calboli wrote: >> >>> Mark, >>>> >>>> To the extent that it may be helpful here and I can do more if need be, I >>>> built 32 bit R 2.12.0 patched on Snow Leopard (10.6.4), using the R BLAS >>>> rather than Apple's veclib. This is on an early 2009 17" MBP with a 2.93 >>>> Ghz Core 2 Duo (MacBookPro5,2) and 4Gb of RAM. >>>> >>>> Based upon Doug's comment in this thread that the issue may be related to >>>> the use of Apple's veclib BLAS, as opposed to R's reference BLAS, I ran >>>> some tests. >>>> >>>> My config includes: >>>> >>>> --without-blas --without-lapack >>>> >>>> just to be sure that the above is the correct invocation, based upon what >>>> I found online. >>>> >>>> Using this build, with all CRAN packages freshly installed using this >>>> build, I ran the example used here with lme4 0.999375-35. I get: >>>> >>>> library(lme4) >>>> y <- (1:20)*pi; x <- (1:20)^2;group <- gl(2,10) >>>> M2. <- lmer (y ~ 1 + x + (1 + x | group)) >>>> M2 <- lmer (y ~ x + ( x | group)) >>>> >>>>> identical(fixef(M2), fixef(M2.)) >>>> [1] TRUE >>>> >>>> >>>> >>>> I then created a function so that I could use replicate() to run this test >>>> a "larger" number of times: >>>> >>>> testlme4 <- function() >>>> { >>>> y <- (1:20)*pi; x <- (1:20)^2;group <- gl(2,10) >>>> M2. <- lmer (y ~ 1 + x + (1 + x | group)) >>>> M2 <- lmer (y ~ x + ( x | group)) >>>> identical(fixef(M2), fixef(M2.)) >>>> } >>>> >>>> >>>> RES <- replicate(1000, testlme4()) >>>> >>>>> all(RES) >>>> [1] TRUE >>>> >>>>> table(RES) >>>> RES >>>> TRUE >>>> 1000 >>>> >>>> Does the example need to be run a "very large" number of times to be sure >>>> that it does not fail, or is the above a reasonable indication that the >>>> use of R's BLAS is a more appropriate default option for R on OSX? If I >>>> am not mistaken (and somebody correct me if wrong), R's BLAS is the >>>> default on Windows and Linux (from my recollections on Fedora). Why should >>>> OSX be different in that regard? >>> >>> Thanks for the very informative post. I added R-Mac in my reply to see if >>> someone can come up with a response to your query. It would also be >>> interesting to know if it were possible to switch the OSX R binary to use >>> the R BLAS library. >>>> >>>> Also, as an aside to Federico, I use 32 bit R on OSX largely because I >>>> have to interact with an Oracle server via RODBC. The only ODBC drivers >>>> available for Oracle on OSX are 32 bit and they are not compatible with 64 >>>> bit R. It would be rather cumbersome when running reports (via Sweave) to >>>> first extract the data in 32 bit R and then switch to 64 bit R to run the >>>> reports. I can run it all in a single step using 32 bit R. I also do not >>>> have a need for the larger memory address space afforded by 64 bit R. >>> >>> I'm very primitive in any integration between R and anything else, so much >>> so that I abandoned Emacs (well integrated with R) for Vim (not as well >>> integrated). On the other hand I do need the greater memory address space >>> of R64. I understand my needs and habits are not universally shared, but, >>> if the *only* reason for using R32 vs R64 is the 20% speed difference, I'd >>> use R64 for running lme4. >> >> >> >> OK, so here is some more data. I wondered if my build using R's BLAS may >> have possibly been a Type II error. So I re-built 32 bit R (same SVN >> checkout code) using: >> >> --with-blas='-framework vecLib' --with-lapack >> >> I then completely removed my old R build (using R's BLAS) and the installed >> CRAN packages. I re-installed R using the above configuration and then >> cleanly re-installed the required CRAN packages. >> >> Here are the results: >> >> y <- (1:20)*pi; x <- (1:20)^2;group <- gl(2,10) >> M2. <- lmer (y ~ 1 + x + (1 + x | group)) >> M2 <- lmer (y ~ x + ( x | group)) >> >>> identical(fixef(M2), fixef(M2.)) >> [1] FALSE >> >> testlme4 <- function() >> { >> y <- (1:20)*pi; x <- (1:20)^2;group <- gl(2,10) >> M2. <- lmer (y ~ 1 + x + (1 + x | group)) >> M2 <- lmer (y ~ x + ( x | group)) >> identical(fixef(M2), fixef(M2.)) >> } >> >> RES <- replicate(1000, testlme4()) >> >>> all(RES) >> [1] FALSE >> >>> table(RES) >> RES >> FALSE TRUE >> 496 504 >> >> So the test in question seems to fail with P(Failure) ~ 0.5 using Apple's >> veclib BLAS. >> >> I should also note that all of my testing is from the CLI using the OSX >> terminal. I do not use R.app. >> >> In response to Huang's reply, regarding his use of the shared lib approach, >> I wonder if there is some other interaction going on, either in the BLAS >> libs, or perhaps in the installed version of lme4, when one BLAS versus the >> other is in use at the time of lme4 installation, since it is installed from >> source on OSX. Note that I used a fully clean build of R and the required >> CRAN packages for each set of tests. >> >> If there is some other testing that I can do, let me know. But the above >> results with a clean build of R and lme4 each time, would seem to further >> reinforce a reconsideration of the use of Apple's veclib BLAS as the default >> for CRAN binary builds of R on OSX. >> >> Regards, >> >> Marc >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
