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.
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.maindon...@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.urba...@r-project.org> wrote:
On Jul 29, 2010, at 7:51 PM, Martin Maechler wrote:
"KB" == Ken Beath <k...@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@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
--
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
