[R-sig-ME] Failure to load lme4 on Mac
John Maindonald
john.maindonald at anu.edu.au
Sat Jul 17 07:51:06 CEST 2010
In principle, maybe a Snow Leopard version might be posted
as an alternative, if someone can provide one. But I take it
that the issue is now a bit wider than tests that fail on Leopard
vs passing on Snow Leopard?
This is I guess an issue for R-devel, but I will float it here first.
It would surely be handy to have a command, maybe status()
would do, so that one could type
> status("lme4")
and receive back details of available binary versions of lme4
on CRAN or on R-forge, or on another relevant site. One might
want to insist on a recent version of R, or on the most recent
version.
John Maindonald email: john.maindonald at anu.edu.au
phone : +61 2 (6125)3473 fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
http://www.maths.anu.edu.au/~johnm
On 17/07/2010, at 3:07 PM, Ken Knoblauch wrote:
> 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
>
> _______________________________________________
> R-sig-mixed-models at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models
More information about the R-sig-mixed-models
mailing list