On Sat, Apr 26, 2014 at 6:37 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Wed, Apr 23, 2014 at 11:59 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Apr 23, 2014 at 1:43 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I'm exploring Mingw-w64 for numpy building, and I've found it gives a slightly different answer for 'exp' than - say - gcc on OSX.
The difference is of the order of the eps value for the output number (2 * eps for a result of ~2.0).
Is accuracy somewhere specified for C functions like exp? Or is accuracy left as an implementation detail for the C library author?
C99 says (sec 5.2.4.2.2) that "The accuracy of the floating point operations ... and of the library functions in <math.h> and <complex.h> that return floating point results is implemenetation defined. The implementation may state that the accuracy is unknown." (This last sentence is basically saying that with regard to some higher up clauses that required all conforming implementations to document this stuff, saying "eh, who knows" counts as documenting it. Hooray for standards!)
Presumably the accuracy in this case is a function of the C library anyway, not the compiler?
Mingw-w64 implementation is in assembly:
http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/math/e...
Numpy has its own implementations for a bunch of the math functions, and it's been unclear in the past whether numpy or the libc implementations were better in any particular case.
I only investigated this particular value, in which case it looked as though the OSX value was closer to the exact value (via sympy.mpmath) - by ~1 unit-at-the-last-place. This was causing a divergence in the powell optimization path and therefore a single scipy test failure. I haven't investigated further - was wondering what investigation I should do, more than running the numpy / scipy test suites.
Investigating further, with this script:
https://gist.github.com/matthew-brett/11301221
The following are tests of np.exp accuracy for input values between 0 and 10, for numpy 1.8.1.
If np.exp(x) performs perfectly, it will return the nearest floating point value to the exact value of exp(x). If it does, this scores a zero for error in the tables below. If 'proportion of zeros' is 1 - then np.exp performs perfectly for all tested values of exp (as is the case for linux here).
OSX 10.9
Proportion of zeros: 0.99789 Sum of error: 2.15021267458e-09 Sum of squared error: 2.47149370032e-14 Max / min error: 5.96046447754e-08 -2.98023223877e-08 Sum of squared relative error: 5.22456992025e-30 Max / min relative error: 2.19700100681e-16 -2.2098803255e-16 eps: 2.22044604925e-16 Proportion of relative err >= eps: 0.0
Debian Jessie / Sid
Proportion of zeros: 1.0 Sum of error: 0.0 Sum of squared error: 0.0 Max / min error: 0.0 0.0 Sum of squared relative error: 0.0 Max / min relative error: 0.0 0.0 eps: 2.22044604925e-16 Proportion of relative err >= eps: 0.0
Mingw-w64 Windows 7
Proportion of zeros: 0.82089 Sum of error: 8.08415331122e-07 Sum of squared error: 2.90045099615e-12 Max / min error: 5.96046447754e-08 -5.96046447754e-08 Sum of squared relative error: 4.18466468175e-28 Max / min relative error: 2.22041308226e-16 -2.22042100773e-16 eps: 2.22044604925e-16 Proportion of relative err >= eps: 0.0
Take-home : exp implementation for mingw-w64 is exactly (floating point) correct 82% of the time, and one unit-at-the-last-place off for the rest [1]. OSX is off by 1 ULP only 0.2% of the time.
Windows 64 with MKL \WinPython-64bit-3.3.2.2\python-3.3.2.amd64>python "E:\Josef\eclipsegworkspace\statsmodels-git\local_scripts\local_scripts\try_exp_error.py" Proportion of zeros: 0.99793 Sum of error: -2.10546855506e-07 Sum of squared error: 3.33304327526e-14 Max / min error: 5.96046447754e-08 -5.96046447754e-08 Sum of squared relative error: 4.98420694339e-30 Max / min relative error: 2.20881302691e-16 -2.18321571939e-16 eps: 2.22044604925e-16 Proportion of relative err >= eps: 0.0 Windows 32 bit python with official MingW binaries Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Proportion of zeros: 0.99464 Sum of error: -3.91621083118e-07 Sum of squared error: 9.2239247812e-14 Max / min error: 5.96046447754e-08 -5.96046447754e-08 Sum of squared relative error: 1.3334972729e-29 Max / min relative error: 2.21593462148e-16 -2.2098803255e-16 eps: 2.22044604925e-16 Proportion of relative err >= eps: 0.0
Is mingw-w64 accurate enough? Do we have any policy on this?
I wouldn't worry about a missing or an extra eps in our applications, but the competition is more accurate. Josef
Cheers,
Matthew
[1] http://matthew-brett.github.io/pydagogue/floating_error.html _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion