From: Mark Dickinson Date: Fri, 1 Aug 2008 09:14:03 +0000 (+0000) Subject: Merged revisions 65366 via svnmerge from X-Git-Tag: v3.0b3~195 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=4aab7119b7293b22c8877bb84593a2510457a626;p=python Merged revisions 65366 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r65366 | mark.dickinson | 2008-08-01 10:13:07 +0100 (Fri, 01 Aug 2008) | 2 lines Tone down math.fsum warning. ........ --- diff --git a/Doc/library/math.rst b/Doc/library/math.rst index df4ec1b69f..da38305aa4 100644 --- a/Doc/library/math.rst +++ b/Doc/library/math.rst @@ -85,29 +85,8 @@ Number-theoretic and representation functions: .. note:: - On platforms where arithmetic results are not correctly rounded, - :func:`fsum` may occasionally produce incorrect results; these - results should be no less accurate than those from the builtin - :func:`sum` function, but nevertheless may have arbitrarily - large relative error. - - In particular, this affects some older Intel hardware (for - example Pentium and earlier x86 processors) that makes use of - 'extended precision' floating-point registers with 64 bits of - precision instead of the 53 bits of precision provided by a C - double. Arithmetic operations using these registers may be - doubly rounded (rounded first to 64 bits, and then rerounded to - 53 bits), leading to incorrectly rounded results. To test - whether your machine is one of those affected, try the following - at a Python prompt:: - - >>> 1e16 + 2.9999 - 10000000000000002.0 - - Machines subject to the double-rounding problem described above - are likely to print ``10000000000000004.0`` instead of - ``10000000000000002.0``. - + The accuracy of fsum() may be impaired on builds that use + extended precision addition and then double-round the results. .. versionadded:: 2.6