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

Reply via email to