Hi,
On Tue, Apr 29, 2014 at 2:08 PM, Kai Tietz ktiet...@googlemail.com wrote:
2014-04-29 21:16 GMT+02:00 Matthew Brett matthew.br...@gmail.com:
Hi,
I'm sorry to ask this question without more information, but I'm
hoping you can give me an idea what more information I need.
Some of us got very interested in using Mingw-w64 as the standard
compiler for Python numerical tools such as numpy and scipy:
https://github.com/numpy/numpy/wiki
http://www.mail-archive.com/numpy-discussion@scipy.org/msg44967.html
One question that came up was the accuracy of the mingw exp function:
http://www.mail-archive.com/numpy-discussion@scipy.org/msg44950.html
I believe this is implemented here:
http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/math/exp.def.h
It looks as if this implementation is slightly less accurate than
other implementations on OSX and Linux:
http://www.mail-archive.com/numpy-discussion@scipy.org/msg44987.html
Specifically, the Linux implementation achieves 100% floating point
accuracy, whereas the Mingw-w64 implementation gets about 80% of
values exactly (floating point) correct, with the remainder off by one
unit at the last place (ULP).
Hmm, well, we use here variant provided by netbsd.
Just to check - you mean the Mingw-w64 assembly should give identical
results to this function in C?
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libm/src/e_exp.c
This 1 ULP thing
isn't necessarily an inaccuracy in general. Mostly it might be either
an issue of rounding, or of method you use to display them. If you
want more accurate value-print I would recommment to use the
__mingw_(printf) functions instead of the MS-C-runtime one. Issue
here is that values by MS-printf getting rounded different (and
sometimes inaccurate).
Yes, sorry, I wasn't very clear. To work out the correct values I
used a multiple precision math library in Python working at 100
decimal digits of precision:
https://gist.github.com/matthew-brett/11301221
I didn't use printf for these values, they are being manipulated as
doubles in Python, with the values for exp comping from calls to exp
via the Python code. So, I think these accuracy values are correct,
and I've checked with equivalent tests for multiplication (guaranteed
to closest floating point value), but I'm happy to hear otherwise.
I writing to ask whether I should investigate this further to see if
another implementation would give better accuracy for similar speed.
Or do y'all consider the current accuracy good enough?
Of course we are interested in approving our math accuracy. It would
be great to improve it. Nevertheless keep please in mind that not all
licenses (and so not all implementations) are acceptable for us.
And for such patches some testcases would be important, too.
Another pretty important thing here is also the
calculation-performance. Another interesting aspect of current
implementation would be to make calculation table-based without use of
x87-FPU instructions (especially for x64).
OK - thanks - then I will investigate further and let you know what I
find, if anything.
Best,
Matthew
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
