From m.pacey at lancaster.ac.uk  Thu Oct 23 12:14:15 2014
From: m.pacey at lancaster.ac.uk (Pacey, Mike)
Date: Thu, 23 Oct 2014 10:14:15 +0000
Subject: [Rd] "make check" fails on lapack.R and stats-Ex.R
In-Reply-To: <1414057588.3225.4.camel@braque.iarc.fr>
References: <737F5642A586344CA8A35D4826EFE56A15F0C6A9@EX-1-MB2.lancs.local>
	<737F5642A586344CA8A35D4826EFE56A15F0C7AE@EX-1-MB2.lancs.local>
	<1414057588.3225.4.camel@braque.iarc.fr>
Message-ID: <737F5642A586344CA8A35D4826EFE56A15F0C9B9@EX-1-MB2.lancs.local>

Hi Martyn,

Thanks for the analysis on that, and I'll remember that test in future - I've not seen a rounding error quite so finely balanced before. I've been using the "-fp-model precise" advice referenced in that document for a while - apparently it wasn't sufficient for this case.

Thanks also to Brian for sanity checking the linear algebra results in a previous post, and apologies for my imprecise terminology.

Regards,
Mike.

-----Original Message-----
From: Martyn Plummer [mailto:plummerm at iarc.fr] 
Sent: 23 October 2014 10:46
To: Pacey, Mike
Cc: r-devel at r-project.org
Subject: Re: [Rd] "make check" fails on lapack.R and stats-Ex.R

On Thu, 2014-10-23 at 08:19 +0000, Pacey, Mike wrote:
> As my attachment doesn't seem to have survived transit, I'm cut'n'pasting the relevant failures here:
> 
> Testing examples for package 'stats'
>   comparing 'stats-Ex.Rout' to 'stats-Ex.Rout.save' ...
> 6466c6466
> < Grand Mean: 291.5937
> ---
> > Grand Mean: 291.5938

I see the same thing, but it is not as bad as it looks. The actual value is 291.59375 so a small amount of numerical error can make the rounding to 4 decimal places go either way:

> print(fit[[1]]$coefficients, digits=16)
      (Intercept)
291.5937500000002 

Note that MKL sacrifices reproducibility (and hence precision) for speed. See more details here:

https://software.intel.com/en-us/articles/run-reproducibility-with-intel-mkl-and-the-intel-compilers

Martyn



[Rd] "make check" fails on lapack.R and stats-Ex.R
Pacey, Mike