From ripley at stats.ox.ac.uk  Sun Apr 10 21:15:31 2005
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Sun Apr 10 21:15:56 2005
Subject: [Rd] make check-all fails (PR#7784)
In-Reply-To: <42597566.6060606@cesmail.net>
References: <20050409182411.C7B2CCA33@slim.kubism.ku.dk>
	<42585C9F.7010903@cesmail.net>
	<x2zmw7knu7.fsf@turmalin.kubism.ku.dk> <42597566.6060606@cesmail.net>
Message-ID: <Pine.LNX.4.61.0504102006180.18859@gannet.stats>

On Sun, 10 Apr 2005, M. Edward (Ed) Borasky wrote:

> Peter Dalgaard wrote:
>
>> "M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:
>> 
>> 
>>> p.dalgaard@biostat.ku.dk wrote:
>>> 
>>> 
>>>> This looks more serious. 100 times machine precision is quite a large
>>>> margin in these matters. Could you perhaps stick in a printout of the
>>>> two terms and their difference?
>>>> 
>>>> I have an ATLAS build on AMD64 and it passes all the checks, but it is
>>>> using ATLAS 3.7.8, so you might want to try an upgrade.
>>>> 
>>>> 
>>>> 
>>> Attached ... you actually weren't very far off:
>>> 
>> ...
>> 
>>>> print (f2[common])
>>>> 
>>>         1          2          3          4          7          8 
>>> 9 32.971099  37.113091  27.472204  16.891921  32.320560  -6.091053 
>>> -26.953745        12         13         14         15         16 
>>> 17         18 
>> ...
>> 
>>> 41.798651  40.734935  40.285066  24.876177   8.442082  46.373463 
>>> 72.652242       118        120        121        122        123        124 
>>> 125 65.983901  81.140660 101.389698  92.784665  86.803528  66.813059 
>>> 76.464152       126        127        128        129        130        131 
>>> 132 85.562396  80.164720  55.046451  22.602751  38.602215  35.466808 
>>> 28.565003       133        134        135        136        137        138 
>>> 139 30.487396  27.515347  17.475536  49.119123  11.994736  14.701687 
>>> 49.795201       140        141        142        143        144        145 
>>> 146  5.664599  24.711067  20.426534  53.013693   5.758723  19.324367 
>>> 41.190110       147        148        149        151        152        153 
>>> 14.189862 -19.275130  35.155615  20.525269  40.584670  18.702940 
>> ...
>> 
>> Aha! 100 times machine precision in not all that much when the numbers
>> themselves are in double digits. In fact, one is over 100. The case
>> that triggers the failure is #149
>> 
>> 
>>>          147           148           149           151           152 
>>> -1.598721e-14 -1.065814e-14 -2.842171e-14 -1.065814e-14 -2.131628e-14 
>> 
>> which is 2 ULP off by my reckoning (scaling 35.15 to be between 0.5
>> and 1 makes the error 2.842e-14/64 =  4.44e-16 and .Machine@double.eps
>> is 2.22e-16).
>> 
>> So again, we might be too strict. I just wonder why we haven't heard
>> of this on any other platforms.
>> 
>> 
> I think it's an Atlas issue, and possibly an Atlas/Athlon32 issue. The 
> built-in BLAS in R-beta don't show this. Is there enough detail on what's 
> happening available for me to take this to the Atlas folks? They've done a 
> lot of work, including assembler code, on Athlons and their 64-bit 
> descendents. My "main system", where I've been doing this testing, is a 
> rather old Athlon T-Bird.
>
> Incidentally, even though Atlas does have most parameters set to pre-defined 
> values for the Athlon/Linux, it does in fact make *some* decisions when it 
> compiles, which may be why I'm showing this and nobody else is. I'm using 
> Gentoo Linux, which recompiles nearly everything from source, including Atlas 
> and R, when it does an install. Most of the other Linux distros have 
> pre-compiled binaries for the various packages. Debian, for example, has 
> pre-compiled Atlas libraries for P3, P4 and Athlon.

I think the issue is ATLAS on your old Athlon.  ATLAS 3.6.0 compiled from 
the sources works correctly with gcc-3.4.3 on my Athlon MP (and also on an 
Athlon XP), but AFAIR those have instructions the Athlon Thunderbird does 
not have.  (Both my machines with such Athlons fried their motherboards, 
so I no longer have access to one.)

Incidentally to Peter: ATLAS 3.7.8 is an unreleased unstable version, so I 
would hesitate to recommend it over 3.6.0.

-- 
Brian D. Ripley,                  ripley@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


[Rd] make check-all fails (PR#7784)
Prof Brian Ripley