[R-SIG-Mac] [R] lme4 + R 2.11.0 + mac unavailable
Martin Maechler
maechler at stat.math.ethz.ch
Sat Jul 31 14:22:53 CEST 2010
On Sat, Jul 31, 2010 at 13:24, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
> Let us be clear about what the issue seems to be. On i386 Mac (and not on
> x86_64 Mac)
>
> 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.))
>
> usually fails the first time but if you run it again it is usually true,
> e.g. following on gave
>
>> fixef(M2); fixef(M2.)
>
> (Intercept) x
> 15.2354383 0.1855865
> (Intercept) x
> 15.2354486 0.1855864
>>
>> M2. <- lmer (y ~ 1 + x + (1 + x | group))
>> fixef(M2.)
>
> (Intercept) x
> 15.2354383 0.1855865
>
> I think 'later version of MacOS' is most likely someone not understanding
> that x86_64 is the default for 'R' on Snow Leopard. I've just checked this
> on Leopard and Snow Leopard. *But* it is not repeatable, as sometimes I get
> TRUE the first run in a session -- and once that happens it seems to keep
> happening until a reboot or I reinstall lme4.
>
> I ran this under valgrind (on Leopard: there is now experimental valgrind
> support for SL, but I've not installed it as yet) and saw no reports of
> problems. However, on one of the times I tried it under valgrind the
> result was further away:
>>
>> fixef(M2.)
>
> (Intercept) x
> 15.2381811 0.1856179
> and persistent.
>
> For completeness, I also saw this using R's reference BLAS rather than the
> (default on a CRAN build) Apple 'veclib' BLAS.
>
> So the issue appears to be one of repeating the calculation and getting
> different answers. That does look like a i386-Mac-specific bug, but whether
> this is worth not distributing a binary for is something for the lme4
> authors to judge -- if not then a platform-specific test opt-out seems the
> best way forward.
Thank you very much, Brian, for your experiments and concluding thoughts.
At the moment (since about yesterday), the R-forge version of lme4 has a test
if(Sys.info()[["sysname"]] != "Darwin")
before two of the stopifnot(identical(..), identical(..)) checks.
Now if I understood correctly, I could constrain the if(..) close even
further by
requiring both "Darwin" and "i386" for "not checking".
So, I'd use
Sys.info()[c("sysname","machine")] == c("Darwin", "i386")
or would you recommend something better?
Thanks again,
Martin
>
> On Sat, 31 Jul 2010, John Maindonald wrote:
>
>> Is optimisation of code a possibility, i.e., the same algebraic
>> calculations done in a slightly different way depending on the state of
>> various registers? E.g., (ab)c vs a(bc), but it would almost certainly be
>> more subtle than that. That seems to me the sort of thing that is likely to
>> be Mac-specific.
>
> But the Mac shares a compiler with lots of other platforms, and the gcc
> optimizer for i386 is pretty much shared across platforms (albeit the Mac
> gcc is now rather old, but is of similar vintage to that used on Windows for
> R 2.11.x). In any case, this is not (in my experiments) an issue of
> numerical accuracy but of repeatability,
>
>>
>> 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 31/07/2010, at 5:09 AM, Martin Maechler wrote:
>>
>>> On Fri, Jul 30, 2010 at 17:29, Simon Urbanek
>>> <simon.urbanek at r-project.org> wrote:
>>>>
>>>> On Jul 29, 2010, at 7:51 PM, Martin Maechler wrote:
>>>>
>>>>>>>>>> "KB" == Ken Beath <ken at kjbeath.com.au>
>>>>>>>>>> on Wed, 28 Jul 2010 01:19:34 -0000 (GMT) writes:
>>>>>
>>>>> KB> On Tue, July 27, 2010 11:07 pm, John Maindonald wrote:
>>>>>>>
>>>>>>> Binaries for lme4 are not for the time being available either on
>>>>>>> CRAN or on r-forge?
>>>>>>>
>>>>>
>>>>> KB> There was a discussion about this on R-Sig-ME. It fails one of the
>>>>> checks
>>>>> KB> on the machine used to build the mac packages. It may pass on
>>>>> machines
>>>>> KB> with a later version of MacOS, but there didn't seem to be a
>>>>> consensus of
>>>>> KB> whether failing the checks was a problem.
>>>>>
>>>>> The underlyign issue seems to remain unresolved.
>>>>> My best guess is still to low-level bugs somewhere in the libraries
>>>>> used.
>>>>>
>>>>> However, to help users,
>>>>> I'm willing to *not* run those tests when *running* on the Mac.
>>>>>
>>>>> What does
>>>>> Sys.info()[["sysname"]]
>>>>>
>>>>> return on the Mac, i.e., different versions of R running on the
>>>>> Mac?
>>>>> From grepping around I'd expect it give "Darwin" in all cases.
>>>>> Is that true?
>>>>>
>>>>
>>>> ... why don't you just compare the values with tolerance? That seems to
>>>> make more sense that to disable the test altogether ...
>>>>
>>>
>>> Doug and I have explained in several occasions (but maybe not on
>>> R-SIG-Mac)
>>> that this is *NOT* the point here.
>>> It's not about "basically the same computations" it's about
>>> identical computations, i.e. from identical numerical matrices and so
>>> the use of identical() has been very much on purpose, and is different
>>> from the well justified typical use of
>>> all.equal() which we use in many other places.
>>>
>>> And what people where reporting *is* a bit disturbing: The same
>>> computations giving different answers for *exactly* the same
>>> computation, e.g., depending if they had used
>>> library(lme4) or require(lme4) to load the package ...
>>> and the difference was not just the last significant bit, but changes
>>> at about the 7-th significant digit.
>>>
>>> Martin
>>>
>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac at stat.math.ethz.ch
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>
> --
> Brian D. Ripley, ripley at 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
>
>
More information about the R-SIG-Mac
mailing list