[Rd] make check-all fails (PR#7784)
Prof Brian Ripley
ripley at stats.ox.ac.uk
Sun Apr 10 21:15:31 CEST 2005
On Sun, 10 Apr 2005, M. Edward (Ed) Borasky wrote:
> Peter Dalgaard wrote:
>
>> "M. Edward (Ed) Borasky" <znmeb at cesmail.net> writes:
>>
>>
>>> p.dalgaard at 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 at 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 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-devel
mailing list