Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
Hi, 27.04.2014 01:37, Matthew Brett kirjoitti: [clip] > 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. > > Is mingw-w64 accurate enough? Do we have any policy on this? I think as mentioned, the C standards don't specify accuracy requirements. Errors of a couple of ULP should be still acceptable. Re: powell test --- if this turns out to be complicated to deal with, just go ahead and disable the trace test. Optimization routines contain statements of the form `if a > b: ...` with floating point numbers, so that the execution path can be sensitive to rounding error if you're unlucky, and the chances go up as the iteration count increases. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
On Sat, Apr 26, 2014 at 8:31 PM, wrote: > > > > On Sat, Apr 26, 2014 at 8:05 PM, wrote: > >> >> >> >> On Sat, Apr 26, 2014 at 6:37 PM, Matthew Brett >> wrote: >> >>> Hi, >>> >>> On Wed, Apr 23, 2014 at 11:59 AM, Matthew Brett >>> wrote: >>> > Hi, >>> > >>> > On Wed, Apr 23, 2014 at 1:43 AM, Nathaniel Smith >>> wrote: >>> >> On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett < >>> matthew.br...@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 and >>> >> 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/exp.def.h >>> > >>> >> 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 >
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
On Sat, Apr 26, 2014 at 8:05 PM, wrote: > > > > On Sat, Apr 26, 2014 at 6:37 PM, Matthew Brett wrote: > >> Hi, >> >> On Wed, Apr 23, 2014 at 11:59 AM, Matthew Brett >> wrote: >> > Hi, >> > >> > On Wed, Apr 23, 2014 at 1:43 AM, Nathaniel Smith wrote: >> >> On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett < >> matthew.br...@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 and >> >> 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/exp.def.h >> > >> >> 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 > > > >>
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
On Sat, Apr 26, 2014 at 6:37 PM, Matthew Brett wrote: > Hi, > > On Wed, Apr 23, 2014 at 11:59 AM, Matthew Brett > wrote: > > Hi, > > > > On Wed, Apr 23, 2014 at 1:43 AM, Nathaniel Smith wrote: > >> On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett > 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 and > >> 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/exp.def.h > > > >> 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://matthe
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
Hi, On Wed, Apr 23, 2014 at 11:59 AM, Matthew Brett wrote: > Hi, > > On Wed, Apr 23, 2014 at 1:43 AM, Nathaniel Smith wrote: >> On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett >> 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 and >> 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/exp.def.h > >> 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. Is mingw-w64 accurate enough? Do we have any policy on this? 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
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
Hi, On Wed, Apr 23, 2014 at 1:43 AM, Nathaniel Smith wrote: > On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett > 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 and > 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/exp.def.h > 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. Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
On Wed, Apr 23, 2014 at 9:43 AM, Nathaniel Smith wrote: > On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett > 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 and > 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? 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. > In the case of MS runtime, at least 9 (as shipped in VS 2008), our implementation is likely to be better (most of the code was taken from the sun math library when the license allowed it). David > > -n > > -- > Nathaniel J. Smith > Postdoctoral researcher - Informatics - University of Edinburgh > http://vorpus.org > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?
On Wed, Apr 23, 2014 at 6:22 AM, Matthew Brett 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 and 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? 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. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Slightly off-topic - accuracy of C exp function?
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? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
