[R-sig-ME] Failure to load lme4 on Mac
Ken Knoblauch
ken.knoblauch at inserm.fr
Sat Jul 17 07:07:06 CEST 2010
Thanks, Martin. I'm wondering if this could be more
widespread, whether it explains an anomaly that cropped
up a few weeks ago when a colleague and I were running the
same code using mgcv, on the same data, me, on my (32 bit) Mac, same
as below and she (her?) under (64 bit) linux. We were getting
slight differences in p-values (and perhaps elsewhere) in
several digits to the right of the decimal point. (She
was in Grenoble and I was in Lyon, just for precision).
No unit tests involved so unless we had been comparing
outputs, any differences would have been insidiously unnoticed.
A short term solution to get a Mac binary up until the
underlying source of this anomaly is brought to light
might be to make these unit tests conditional on not
being a Mac, but you might find that (understandably) less than righteous
in that it is letting people generate results with potentially
small errors (as far as we know at this point) leaking in
without any protection.
best,
Ken
Quoting Martin Maechler <maechler at stat.math.ethz.ch>:
>>>>>> "KK" == Ken Knoblauch <ken.knoblauch at inserm.fr>
>>>>>> on Fri, 16 Jul 2010 13:51:23 +0000 (UTC) writes:
>
> [...........]
>
> >> The CRAN machine is Mac OS X 10.5.8 with Xcode 3.1.4
> >> (using gcc-4.2) which is indeed the latest Xcode version
> >> for Leopard. If you have any hints as of why lme4 may be
> >> failing they are highly appreciated.
>
> >> Thanks,
> >> Simon
>
> [.......................]
>
> KK> Just having updated Xcode to 3.1.4 and fixed the versions of
> gcc, etc. so
> KK> that I'm able to install latest version of Rcpp and lme4a without any
> KK> problems,
> KK> I'll take a bite, but maybe I'm just repeating what you have
> already seen.
> KK> I can install lme4 from source from Rforge with no problem.
> KK> Just for starters here is my sessionInfo
> KK> R version 2.11.1 Patched (2010-07-15 r52539)
> KK> i386-apple-darwin9.8.0
>
> KK> locale:
> KK> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>
> KK> attached base packages:
> KK> [1] stats graphics grDevices utils datasets methods
> KK> [7] base
>
> KK> other attached packages:
> KK> [1] lme4_0.999375-34 Matrix_0.999375-41 lattice_0.18-8
>
> KK> loaded via a namespace (and not attached):
> KK> [1] grid_2.11.1 nlme_3.1-96 stats4_2.11.1
>
> KK> I dowloaded lme4_0.999375-34.tar.gz from CRAN and ran
> KK> R CMD check on it and came up with
> KK> * checking tests ...
> KK> Running ‘extras.R’
> KK> Running ‘lmer-1.R’
> KK> ERROR
> KK> Running the tests in 'tests/lmer-1.R' failed.
> KK> Last 13 lines of output:
> KK> + x3=rnorm(20,1))
> >> m0 <- lmer(y ~ (x1 + x2)|ff, data = D)
> >> m1 <- lmer(y ~ x1 + x2|ff , data = D)
> >> m2 <- lmer(y ~ x1 + (x2|ff), data = D)
> >> m3 <- lmer(y ~ (x2|ff) + x1, data = D)
> >> stopifnot(identical(ranef(m0), ranef(m1)),
> KK> + identical(ranef(m2), ranef(m3)),
> KK> + inherits(tryCatch(lmer(y ~ x2|ff + x1, data = D), error
> = function(e)e),
> KK> + "error"))
> KK> Error: identical(ranef(m0), ranef(m1)) is not TRUE
> KK> In addition: Warning message:
> KK> In Ops.factor(ff, x1) : + not meaningful for factors
> KK> Execution halted
> KK> which I think is the reported problem.
>
> Yes, one of the typical two ones.
>
> The other one that Mac useRs, e.g., Kent Holsinger, in a private
> communication, have also encountered, is the even simpler case
> {earlier in lmer-1.R, so this means it did not trigger for
> *you*}:
>
> y <- (1:20)*pi
> x <- (1:20)^2
> group <- gl(2,10)
>
> stopifnot(require(lme4))
> sessionInfo()
>
> M2. <- lmer (y ~ 1 + x + (1 + x | group))
> M2 <- lmer (y ~ x + ( x | group))
>
> ## should be identical (and is .. well, not on all versions on Mac OSX):
> identical(ranef(M2), ranef(M2.))
> ## not TRUE on some Mac : OSX : R combinations
>
>
> How can the linear algebra computations that start from
> identical numbers give different results *sometimes* on Mac OSX?
> Could it be that it uses some Mac specific BLAS/LAPACK
> optimizations which only happen *sometimes* ?
>
> KK> I went into the file lmer-1.R which seems to be where this is
> KK> coming from
>
> [correct]
>
> KK> and sourced the lines indicated above and get
>
> >> D <- data.frame(y= rnorm(20,10), ff = gl(4,5),
> KK> + x1=rnorm(20,3), x2=rnorm(20,7),
> KK> + x3=rnorm(20,1))
> >> m0 <- lmer(y ~ (x1 + x2)|ff, data = D)
> >> m1 <- lmer(y ~ x1 + x2|ff , data = D)
> >> m2 <- lmer(y ~ x1 + (x2|ff), data = D)
> >> m3 <- lmer(y ~ (x2|ff) + x1, data = D)
> >> stopifnot(identical(ranef(m0), ranef(m1)),
> KK> + identical(ranef(m2), ranef(m3)),
> KK> + inherits(tryCatch(lmer(y ~ x2|ff + x1, data = D), error =
> KK> function(e)e),
> KK> + "error"))
> KK> Error: identical(ranef(m2), ranef(m3)) is not TRUE
> KK> In addition: Warning message:
> KK> In Ops.factor(ff, x1) : + not meaningful for factors
> >> identical(ranef(m0), ranef(m1))
> KK> [1] TRUE
>
> >> identical(ranef(m2), ranef(m3))
> KK> [1] FALSE
>
> KK> so it happens in an R session as well.
>
> yes.
> So,
> m2 <- lmer(y ~ x1 + (x2|ff), data = D)
> m3 <- lmer(y ~ (x2|ff) + x1, data = D)
>
> give differing results? How come?
> It seems as curious as the above simpler case,
> as really the initial starting matrices must be identical,
> unless the mac CPU does some things slightly differently
> depending on the exact machine configuration ???
>
> To me that could mean that even two identical R statements
> could give very slightly differing results, depending on the
> exact circumstance in which they are called {and of course I'm
> not talking about things that depend on options() or global
> variables or different search(), ...}
>
> ??
>
> KK> Checking the ranef's
> >> ranef(m2)
> KK> $ff
> KK> (Intercept) x2
> KK> 1 -1.4142222 0.15618464
> KK> 2 0.4787662 -0.05287424
> KK> 3 0.3193410 -0.03526755
> KK> 4 1.7224362 -0.19022335
>
> >> ranef(m3)
> KK> $ff
> KK> (Intercept) x2
> KK> 1 -1.4141930 0.15618142
> KK> 2 0.4787944 -0.05287736
> KK> 3 0.3193632 -0.03527000
> KK> 4 1.7224652 -0.19022656
>
> KK> They do indeed differ. I'm on a 32 bit machine, could this be
> KK> a 32/64 bit difference or something at the level of BLAS/ATLAS level?
> KK> That's out of my league. If I have time, I'll try it on a
> 64 bit Mac, but I'm
> KK> not likely to get back to that before about the beginning of August.
>
>
> KK> Hope that this is useful.
>
> KK> Ken
>
> KK> --
> KK> Ken Knoblauch
> KK> Inserm U846
> KK> Stem-cell and Brain Research Institute
> KK> Department of Integrative Neurosciences
> KK> 18 avenue du Doyen Lépine
> KK> 69500 Bron
> KK> France
> KK> tel: +33 (0)4 72 91 34 77
> KK> fax: +33 (0)4 72 91 34 61
> KK> portable: +33 (0)6 84 10 64 10
> KK> http://www.sbri.fr/members/kenneth-knoblauch.html
>
> KK> _______________________________________________
> KK> R-sig-mixed-models at r-project.org mailing list
> KK> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models
>
--
Ken Knoblauch
Inserm U846
Stem-cell and Brain Research Institute
Department of Integrative Neurosciences
18 avenue du Doyen Lépine
69500 Bron
France
tel: +33 (0)4 72 91 34 77
fax: +33 (0)4 72 91 34 61
portable: +33 (0)6 84 10 64 10
http://www.sbri.fr/members/kenneth-knoblauch.html
More information about the R-sig-mixed-models
mailing list