[SciPy-User] understanding machine precision

Bruce Southey bsouthey at gmail.com
Wed Dec 15 12:31:30 EST 2010


On 12/15/2010 06:43 AM, josef.pktd at gmail.com wrote:
> On Tue, Dec 14, 2010 at 3:17 PM, Keith Goodman<kwgoodman at gmail.com>  wrote:
>> On Tue, Dec 14, 2010 at 11:38 AM,<josef.pktd at gmail.com>  wrote:
>>> On Tue, Dec 14, 2010 at 2:29 PM, Francesc Alted<faltet at pytables.org>  wrote:
>>>> A Tuesday 14 December 2010 20:17:10 Nils Wagner escrigué:
>>>>> Hi all,
>>>>>
>>>>> I am using ATLAS
>>>>>
>>>>> python -i try_deterministic.py
>>>>>
>>>>> lstsq
>>>>> 0.0
>>>>> 0.0
>>>>> 0.0
>>>>> 0.0
>>>>> 0.0
>>>> That's interesting.  Maybe Josef is using a threaded ATLAS?  I
>>>> positively know that threading introduces variability in the order that
>>>> the computations are done.  However, I'm not sure on why ATLAS has
>>>> decided to use several threads for so small matrices ((100, 10)) :-/
>>> No, I'm using an old plain ATLAS with a single CPU, but if Skipper is
>>> getting it also with 32bit mkl, then there might still be another
>>> Windows "feature" in play.
>>>
>>> Since my results are identical across python session, but not within,
>>> the results are still deterministic and cannot depend on how busy my
>>> computer is.
>> Come to think if it, one of my tests is to compare the output of each
>> new release of one of my packages with the previous release. My
>> colleague runs the test on a windows machine. He gets a difference in
>> output when there should be none. Even after pulling the installer
>> apart and installing the non-ATLAS version he sees the difference on
>> windows. It would be great to figure out what is going on.
> It looks like it's Windows32 specific, but not specific to an ATLAS or
> LAPACK version.
>
> I still don't have a clue why, but it looks like tests that use linalg
> have to be weakened to decimal=14 or decimal=15, larger than I thought
> previously.
>
> Thanks,
>
> Josef
Can you please detail the versions of Python and numpy as well as how 
each was built? Does it use sse and does it use the gcc option 
'-fexcess-precision'?

Given Skipper's response, it may be due to cross-compiling (including 
compiler and OS differences) as well as being at the limits of numerical 
accuracy for that precision (loss of significance or precision). 
(Reading gcc bug 323 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323) 
is interesting or not.)

Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20101215/7a3db1e2/attachment.html>


More information about the SciPy-User mailing list