Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
Hi Julian,
to distinguish between mingw32 and mingw-w64 we need something like this:
#include stdlib.h
if !defined(HAVE_EXPM1) || defined(__MINGW64_VERSION_MAJOR)
instead of
if !defined(HAVE_EXPM1) || defined(__MINGW32__)
the latter is true for both: mingw32 and mingw-w64. I guess the mingw32
implementation of expm1 is again different.
stdlib.h has to be included to define __MINGW64_VERSION_MAJOR
2014-04-23 23:27 GMT+02:00 Julian Taylor jtaylor.deb...@googlemail.com:
On 23.04.2014 21:25, Matthew Brett wrote:
Hi,
On Tue, Apr 15, 2014 at 12:34 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On Tue, Apr 15, 2014 at 4:30 AM, Matthew Brett matthew.br...@gmail.com
wrote:
It looks as though mingw-w64 is at fault, and I was confused (still
am) because of the different behavior with double and a constant:
#include stdio.h
#include math.h
int main() {
double z, i = -0.0;
printf(With double %f=%f, with constant=%f\n,
i, expm1(i), expm1(-0.));
}
gives:
With double -0.00=0.00, with constant=-0.00
That was ugly to track down.
What is the right way to work round this (using the numpy version
instead of the system version I suppose)?
The right way is to file a bug at mingw and get it fixed at the source.
http://sourceforge.net/p/mingw-w64/code/6594/
great thanks for reporting it.
Additionally as this time npymath seems to be better (thats 3 bugs in
npymath vs 1 in mingw on my scoreboard) one could use the mingw
preprocessor define instead of HAVE_EXP1M to select this function from
npymath.
Sorry to be slow - could you unpack what you mean in this paragraph?
Is there a way to force use of the numpy version of the function using
environment variables or similar?
I mean something along the line of attached patch, maybe you can try it.
If it works I can file a numpy PR.
___
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] Test error with ATLAS, Windows 64 bit
Hi,
On Tue, Apr 15, 2014 at 12:34 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On Tue, Apr 15, 2014 at 4:30 AM, Matthew Brett matthew.br...@gmail.com
wrote:
It looks as though mingw-w64 is at fault, and I was confused (still
am) because of the different behavior with double and a constant:
#include stdio.h
#include math.h
int main() {
double z, i = -0.0;
printf(With double %f=%f, with constant=%f\n,
i, expm1(i), expm1(-0.));
}
gives:
With double -0.00=0.00, with constant=-0.00
That was ugly to track down.
What is the right way to work round this (using the numpy version
instead of the system version I suppose)?
The right way is to file a bug at mingw and get it fixed at the source.
http://sourceforge.net/p/mingw-w64/code/6594/
Additionally as this time npymath seems to be better (thats 3 bugs in
npymath vs 1 in mingw on my scoreboard) one could use the mingw
preprocessor define instead of HAVE_EXP1M to select this function from
npymath.
Sorry to be slow - could you unpack what you mean in this paragraph?
Is there a way to force use of the numpy version of the function using
environment variables or similar?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On 23.04.2014 21:25, Matthew Brett wrote:
Hi,
On Tue, Apr 15, 2014 at 12:34 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On Tue, Apr 15, 2014 at 4:30 AM, Matthew Brett matthew.br...@gmail.com
wrote:
It looks as though mingw-w64 is at fault, and I was confused (still
am) because of the different behavior with double and a constant:
#include stdio.h
#include math.h
int main() {
double z, i = -0.0;
printf(With double %f=%f, with constant=%f\n,
i, expm1(i), expm1(-0.));
}
gives:
With double -0.00=0.00, with constant=-0.00
That was ugly to track down.
What is the right way to work round this (using the numpy version
instead of the system version I suppose)?
The right way is to file a bug at mingw and get it fixed at the source.
http://sourceforge.net/p/mingw-w64/code/6594/
great thanks for reporting it.
Additionally as this time npymath seems to be better (thats 3 bugs in
npymath vs 1 in mingw on my scoreboard) one could use the mingw
preprocessor define instead of HAVE_EXP1M to select this function from
npymath.
Sorry to be slow - could you unpack what you mean in this paragraph?
Is there a way to force use of the numpy version of the function using
environment variables or similar?
I mean something along the line of attached patch, maybe you can try it.
If it works I can file a numpy PR.
diff --git a/numpy/core/src/npymath/npy_math.c.src b/numpy/core/src/npymath/npy_math.c.src
index 1ca7033..e371061 100644
--- a/numpy/core/src/npymath/npy_math.c.src
+++ b/numpy/core/src/npymath/npy_math.c.src
@@ -62,7 +62,9 @@
*/
/* Original code by Konrad Hinsen. */
-#ifndef HAVE_EXPM1
+#if !defined(HAVE_EXPM1) || defined(__MINGW32__)
+/* http://sourceforge.net/p/mingw-w64/code/6594/ */
+#define NPY_USE_OWN_EXPM1 1
double npy_expm1(double x)
{
if (npy_isinf(x) x 0) {
@@ -80,6 +82,8 @@ double npy_expm1(double x)
}
}
}
+#else
+#define NPY_USE_OWN_EXPM1 0
#endif
#ifndef HAVE_LOG1P
@@ -335,12 +339,13 @@ double npy_log2(double x)
* log,exp,expm1,asin,acos,atan,asinh,acosh,atanh,log1p,exp2,log2#
* #KIND = SIN,COS,TAN,SINH,COSH,TANH,FABS,FLOOR,CEIL,RINT,TRUNC,SQRT,LOG10,
* LOG,EXP,EXPM1,ASIN,ACOS,ATAN,ASINH,ACOSH,ATANH,LOG1P,EXP2,LOG2#
+ * #skip = 0*15,NPY_USE_OWN_EXPM1,0*9#
*/
#ifdef @kind@@c@
#undef @kind@@c@
#endif
-#ifndef HAVE_@KIND@@C@
+#if !defined HAVE_@KIND@@C@ || @skip@
@type@ npy_@kind@@c@(@type@ x)
{
return (@type@) npy_@kind@((double)x);
@@ -394,8 +399,9 @@ double npy_log2(double x)
* log,exp,expm1,asin,acos,atan,asinh,acosh,atanh,log1p,exp2,log2#
* #KIND = SIN,COS,TAN,SINH,COSH,TANH,FABS,FLOOR,CEIL,RINT,TRUNC,SQRT,LOG10,
* LOG,EXP,EXPM1,ASIN,ACOS,ATAN,ASINH,ACOSH,ATANH,LOG1P,EXP2,LOG2#
+ * #skip = 0*15,NPY_USE_OWN_EXPM1,0*9#
*/
-#ifdef HAVE_@KIND@@C@
+#if defined HAVE_@KIND@@C@ !@skip@
@type@ npy_@kind@@c@(@type@ x)
{
return @kind@@c@(x);
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
Hi,
On Wed, Apr 23, 2014 at 2:27 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On 23.04.2014 21:25, Matthew Brett wrote:
Hi,
On Tue, Apr 15, 2014 at 12:34 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On Tue, Apr 15, 2014 at 4:30 AM, Matthew Brett matthew.br...@gmail.com
wrote:
It looks as though mingw-w64 is at fault, and I was confused (still
am) because of the different behavior with double and a constant:
#include stdio.h
#include math.h
int main() {
double z, i = -0.0;
printf(With double %f=%f, with constant=%f\n,
i, expm1(i), expm1(-0.));
}
gives:
With double -0.00=0.00, with constant=-0.00
That was ugly to track down.
What is the right way to work round this (using the numpy version
instead of the system version I suppose)?
The right way is to file a bug at mingw and get it fixed at the source.
http://sourceforge.net/p/mingw-w64/code/6594/
great thanks for reporting it.
Additionally as this time npymath seems to be better (thats 3 bugs in
npymath vs 1 in mingw on my scoreboard) one could use the mingw
preprocessor define instead of HAVE_EXP1M to select this function from
npymath.
Sorry to be slow - could you unpack what you mean in this paragraph?
Is there a way to force use of the numpy version of the function using
environment variables or similar?
I mean something along the line of attached patch, maybe you can try it.
If it works I can file a numpy PR.
Thanks for the patch - I see what you mean now.
I wonder if there should be some mechanism by which different
compilers can set these? What was the issue with MSVC for example -
does it need something like this too?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Tue, Apr 15, 2014 at 4:30 AM, Matthew Brett matthew.br...@gmail.com wrote:
It looks as though mingw-w64 is at fault, and I was confused (still
am) because of the different behavior with double and a constant:
#include stdio.h
#include math.h
int main() {
double z, i = -0.0;
printf(With double %f=%f, with constant=%f\n,
i, expm1(i), expm1(-0.));
}
gives:
With double -0.00=0.00, with constant=-0.00
That was ugly to track down.
What is the right way to work round this (using the numpy version
instead of the system version I suppose)?
The right way is to file a bug at mingw and get it fixed at the source.
Additionally as this time npymath seems to be better (thats 3 bugs in
npymath vs 1 in mingw on my scoreboard) one could use the mingw
preprocessor define instead of HAVE_EXP1M to select this function from
npymath.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Test error with ATLAS, Windows 64 bit
Hi, With Carl Kleffner, I am trying to build a numpy 1.8.1 wheel for Windows 64-bit, and latest stable ATLAS. It works fine, apart from the following test failure: == FAIL: test_special (test_umath.TestExpm1) -- Traceback (most recent call last): File C:\Python27\lib\site-packages\numpy\core\tests\test_umath.py, line 329, in test_special assert_equal(ncu.expm1(-0.), -0.) File C:\Python27\lib\site-packages\numpy\testing\utils.py, line 311, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0.0 DESIRED: -0.0 Has anyone seen this? Is it in fact necessary that expm1(-0.) return -0 instead of 0? Thanks a lot, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Mon, Apr 14, 2014 at 2:59 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, With Carl Kleffner, I am trying to build a numpy 1.8.1 wheel for Windows 64-bit, and latest stable ATLAS. It works fine, apart from the following test failure: == FAIL: test_special (test_umath.TestExpm1) -- Traceback (most recent call last): File C:\Python27\lib\site-packages\numpy\core\tests\test_umath.py, line 329, in test_special assert_equal(ncu.expm1(-0.), -0.) File C:\Python27\lib\site-packages\numpy\testing\utils.py, line 311, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0.0 DESIRED: -0.0 Has anyone seen this? Is it in fact necessary that expm1(-0.) return -0 instead of 0? What a cowinky dink. This moring I ran into this issue in a scipy pull request (https://github.com/scipy/scipy/pull/3547), and I asked about this comparison failing on the mailing list a few hours ago. In the pull request, the modified function returns -0.0 where it used to return 0.0, and the test for the value 0.0 failed. My work-around was to use `assert_array_equal` instead of `assert_equal`. The array comparison functions treat the values -0.0 and 0.0 as equal. `assert_equal` has code that checks for signed zeros, and fails if they are not the same sign. Warren Thanks a lot, Matthew ___ 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] Test error with ATLAS, Windows 64 bit
Hi, On Mon, Apr 14, 2014 at 12:12 PM, Warren Weckesser warren.weckes...@gmail.com wrote: On Mon, Apr 14, 2014 at 2:59 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, With Carl Kleffner, I am trying to build a numpy 1.8.1 wheel for Windows 64-bit, and latest stable ATLAS. It works fine, apart from the following test failure: == FAIL: test_special (test_umath.TestExpm1) -- Traceback (most recent call last): File C:\Python27\lib\site-packages\numpy\core\tests\test_umath.py, line 329, in test_special assert_equal(ncu.expm1(-0.), -0.) File C:\Python27\lib\site-packages\numpy\testing\utils.py, line 311, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0.0 DESIRED: -0.0 Has anyone seen this? Is it in fact necessary that expm1(-0.) return -0 instead of 0? What a cowinky dink. This moring I ran into this issue in a scipy pull request (https://github.com/scipy/scipy/pull/3547), and I asked about this comparison failing on the mailing list a few hours ago. In the pull request, the modified function returns -0.0 where it used to return 0.0, and the test for the value 0.0 failed. My work-around was to use `assert_array_equal` instead of `assert_equal`. The array comparison functions treat the values -0.0 and 0.0 as equal. `assert_equal` has code that checks for signed zeros, and fails if they are not the same sign. Yes, sorry, I should have mentioned that I saw your post too. I'd live to use that workaround, but it looks like the teste against -0 is intentional, and I was hoping for help understanding. The relevant two lines of the test are: assert_equal(ncu.expm1(0.), 0.) assert_equal(ncu.expm1(-0.), -0.) Julian - I think this one is for you - as the author of these lines: f53ab41a numpy/core/tests/test_umath.py (Julian Taylor 2014-03-02 02:55:30 +0100 329) assert_equal(ncu.expm1(-0.), -0.) Can you say why you wanted -0 specifically? Any clue as to why ATLAS 64 bit may give 0 instead? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Monday, April 14, 2014, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Mon, Apr 14, 2014 at 12:12 PM, Warren Weckesser warren.weckes...@gmail.com javascript:; wrote: On Mon, Apr 14, 2014 at 2:59 PM, Matthew Brett matthew.br...@gmail.comjavascript:; wrote: Hi, With Carl Kleffner, I am trying to build a numpy 1.8.1 wheel for Windows 64-bit, and latest stable ATLAS. It works fine, apart from the following test failure: == FAIL: test_special (test_umath.TestExpm1) -- Traceback (most recent call last): File C:\Python27\lib\site-packages\numpy\core\tests\test_umath.py, line 329, in test_special assert_equal(ncu.expm1(-0.), -0.) File C:\Python27\lib\site-packages\numpy\testing\utils.py, line 311, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0.0 DESIRED: -0.0 Has anyone seen this? Is it in fact necessary that expm1(-0.) return -0 instead of 0? What a cowinky dink. This moring I ran into this issue in a scipy pull request (https://github.com/scipy/scipy/pull/3547), and I asked about this comparison failing on the mailing list a few hours ago. In the pull request, the modified function returns -0.0 where it used to return 0.0, and the test for the value 0.0 failed. My work-around was to use `assert_array_equal` instead of `assert_equal`. The array comparison functions treat the values -0.0 and 0.0 as equal. `assert_equal` has code that checks for signed zeros, and fails if they are not the same sign. Yes, sorry, I should have mentioned that I saw your post too. I'd live to use that workaround, but it looks like the teste against -0 is intentional, and I was hoping for help understanding. The relevant two lines of the test are: assert_equal(ncu.expm1(0.), 0.) assert_equal(ncu.expm1(-0.), -0.) Julian - I think this one is for you - as the author of these lines: f53ab41a numpy/core/tests/test_umath.py (Julian Taylor 2014-03-02 02:55:30 +0100 329) assert_equal(ncu.expm1(-0.), -0.) Can you say why you wanted -0 specifically? Any clue as to why ATLAS 64 bit may give 0 instead? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org javascript:; http://mail.scipy.org/mailman/listinfo/numpy-discussion I think this is a real bug in the version of exp1m in core/src/npymath/npy_math.c.src that's being used since your windows build couldn't find a system version of exp1m to use. Eric ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
Hi, mingw has expm1. Is this function suitable? Regards Carl 2014-04-14 21:34 GMT+02:00 Eric Moore e...@redtetrahedron.org: On Monday, April 14, 2014, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Mon, Apr 14, 2014 at 12:12 PM, Warren Weckesser warren.weckes...@gmail.com wrote: On Mon, Apr 14, 2014 at 2:59 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, With Carl Kleffner, I am trying to build a numpy 1.8.1 wheel for Windows 64-bit, and latest stable ATLAS. It works fine, apart from the following test failure: == FAIL: test_special (test_umath.TestExpm1) -- Traceback (most recent call last): File C:\Python27\lib\site-packages\numpy\core\tests\test_umath.py, line 329, in test_special assert_equal(ncu.expm1(-0.), -0.) File C:\Python27\lib\site-packages\numpy\testing\utils.py, line 311, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0.0 DESIRED: -0.0 Has anyone seen this? Is it in fact necessary that expm1(-0.) return -0 instead of 0? What a cowinky dink. This moring I ran into this issue in a scipy pull request (https://github.com/scipy/scipy/pull/3547), and I asked about this comparison failing on the mailing list a few hours ago. In the pull request, the modified function returns -0.0 where it used to return 0.0, and the test for the value 0.0 failed. My work-around was to use `assert_array_equal` instead of `assert_equal`. The array comparison functions treat the values -0.0 and 0.0 as equal. `assert_equal` has code that checks for signed zeros, and fails if they are not the same sign. Yes, sorry, I should have mentioned that I saw your post too. I'd live to use that workaround, but it looks like the teste against -0 is intentional, and I was hoping for help understanding. The relevant two lines of the test are: assert_equal(ncu.expm1(0.), 0.) assert_equal(ncu.expm1(-0.), -0.) Julian - I think this one is for you - as the author of these lines: f53ab41a numpy/core/tests/test_umath.py (Julian Taylor 2014-03-02 02:55:30 +0100 329) assert_equal(ncu.expm1(-0.), -0.) Can you say why you wanted -0 specifically? Any clue as to why ATLAS 64 bit may give 0 instead? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion I think this is a real bug in the version of exp1m in core/src/npymath/npy_math.c.src that's being used since your windows build couldn't find a system version of exp1m to use. Eric ___ 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] Test error with ATLAS, Windows 64 bit
The official numpy mingw binaries do not have all these math issues. Only the VC builds do. As mingw is fine the functions must be somewhere in the windows API but no-one has contributed a fix for the VC builds to numpy yet. On 14.04.2014 22:43, Carl Kleffner wrote: Hi, mingw has expm1. Is this function suitable? Regards Carl 2014-04-14 21:34 GMT+02:00 Eric Moore e...@redtetrahedron.org mailto:e...@redtetrahedron.org: On Monday, April 14, 2014, Matthew Brett matthew.br...@gmail.com mailto:matthew.br...@gmail.com wrote: Hi, On Mon, Apr 14, 2014 at 12:12 PM, Warren Weckesser warren.weckes...@gmail.com wrote: On Mon, Apr 14, 2014 at 2:59 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, With Carl Kleffner, I am trying to build a numpy 1.8.1 wheel for Windows 64-bit, and latest stable ATLAS. It works fine, apart from the following test failure: == FAIL: test_special (test_umath.TestExpm1) -- Traceback (most recent call last): File C:\Python27\lib\site-packages\numpy\core\tests\test_umath.py, line 329, in test_special assert_equal(ncu.expm1(-0.), -0.) File C:\Python27\lib\site-packages\numpy\testing\utils.py, line 311, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0.0 DESIRED: -0.0 Has anyone seen this? Is it in fact necessary that expm1(-0.) return -0 instead of 0? What a cowinky dink. This moring I ran into this issue in a scipy pull request (https://github.com/scipy/scipy/pull/3547), and I asked about this comparison failing on the mailing list a few hours ago. In the pull request, the modified function returns -0.0 where it used to return 0.0, and the test for the value 0.0 failed. My work-around was to use `assert_array_equal` instead of `assert_equal`. The array comparison functions treat the values -0.0 and 0.0 as equal. `assert_equal` has code that checks for signed zeros, and fails if they are not the same sign. Yes, sorry, I should have mentioned that I saw your post too. I'd live to use that workaround, but it looks like the teste against -0 is intentional, and I was hoping for help understanding. The relevant two lines of the test are: assert_equal(ncu.expm1(0.), 0.) assert_equal(ncu.expm1(-0.), -0.) Julian - I think this one is for you - as the author of these lines: f53ab41a numpy/core/tests/test_umath.py (Julian Taylor 2014-03-02 02:55:30 +0100 329) assert_equal(ncu.expm1(-0.), -0.) Can you say why you wanted -0 specifically? Any clue as to why ATLAS 64 bit may give 0 instead? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion I think this is a real bug in the version of exp1m in core/src/npymath/npy_math.c.src that's being used since your windows build couldn't find a system version of exp1m to use. Eric ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto: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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
Hi,
On Mon, Apr 14, 2014 at 2:02 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
The official numpy mingw binaries do not have all these math issues.
Only the VC builds do.
As mingw is fine the functions must be somewhere in the windows API but
no-one has contributed a fix for the VC builds to numpy yet.
I'm building with mingw-w64.
It looks like this works as expected from this test:
#include math.h
#include stdio.h
int main() {
double z;
z = expm1(-0.0);
printf(Result %f\n, z);
}
(prints -0).
as does this (modified from core/src/npymath/npy_math.c.src):
#include stdio.h
double npy_expm1(double x)
{
if (isinf(x) x 0) {
return x;
}
else {
const double u = exp(x);
if (u == 1.0) {
return x;
} else if (u - 1.0 == -1.0) {
return -1;
} else {
return (u - 1.0) * x/log(u);
}
}
}
int main() {
double z;
z = npy_expm1(-0.0);
printf(Result %f\n, z);
}
Sorry for my ignorance, but where does the `HAVE_EXPM1` symbol come from?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Mon, Apr 14, 2014 at 3:38 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Mon, Apr 14, 2014 at 2:02 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
The official numpy mingw binaries do not have all these math issues.
Only the VC builds do.
As mingw is fine the functions must be somewhere in the windows API but
no-one has contributed a fix for the VC builds to numpy yet.
I'm building with mingw-w64.
It looks like this works as expected from this test:
#include math.h
#include stdio.h
int main() {
double z;
z = expm1(-0.0);
printf(Result %f\n, z);
}
(prints -0).
as does this (modified from core/src/npymath/npy_math.c.src):
#include stdio.h
double npy_expm1(double x)
{
if (isinf(x) x 0) {
return x;
}
else {
const double u = exp(x);
if (u == 1.0) {
return x;
} else if (u - 1.0 == -1.0) {
return -1;
} else {
return (u - 1.0) * x/log(u);
}
}
}
int main() {
double z;
z = npy_expm1(-0.0);
printf(Result %f\n, z);
}
Sorry for my ignorance, but where does the `HAVE_EXPM1` symbol come from?
Remember all configuration output at the beginning of the build? One of
those tries to link 'expm1{f, , l}' and sets the value of
'HAVE_EXPM1{F,,L}' accordingly. You can find the result in the `config.h`
file in the build directory.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Mon, Apr 14, 2014 at 10:02 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: The official numpy mingw binaries do not have all these math issues. Only the VC builds do. As mingw is fine the functions must be somewhere in the windows API but no-one has contributed a fix for the VC builds to numpy yet. Mingw generally has their own implementation, and do not use the C runtime from MS for math functions: https://github.com/mirror/mingw-w64/tree/master/trunk/mingw-w64-crt/math David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
Hi,
On Mon, Apr 14, 2014 at 2:58 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Apr 14, 2014 at 3:38 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Mon, Apr 14, 2014 at 2:02 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
The official numpy mingw binaries do not have all these math issues.
Only the VC builds do.
As mingw is fine the functions must be somewhere in the windows API but
no-one has contributed a fix for the VC builds to numpy yet.
I'm building with mingw-w64.
It looks like this works as expected from this test:
#include math.h
#include stdio.h
int main() {
double z;
z = expm1(-0.0);
printf(Result %f\n, z);
}
(prints -0).
as does this (modified from core/src/npymath/npy_math.c.src):
#include stdio.h
double npy_expm1(double x)
{
if (isinf(x) x 0) {
return x;
}
else {
const double u = exp(x);
if (u == 1.0) {
return x;
} else if (u - 1.0 == -1.0) {
return -1;
} else {
return (u - 1.0) * x/log(u);
}
}
}
int main() {
double z;
z = npy_expm1(-0.0);
printf(Result %f\n, z);
}
Sorry for my ignorance, but where does the `HAVE_EXPM1` symbol come from?
Remember all configuration output at the beginning of the build? One of
those tries to link 'expm1{f, , l}' and sets the value of 'HAVE_EXPM1{F,,L}'
accordingly. You can find the result in the `config.h` file in the build
directory.
Ah - thanks - that got me going - somewhere.
I noticed that HAVE_EXPM1 is not defined in any of OSX, my Windows
build, Debian config.h - is that expected?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Mon, Apr 14, 2014 at 4:40 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Mon, Apr 14, 2014 at 2:58 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Apr 14, 2014 at 3:38 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Mon, Apr 14, 2014 at 2:02 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
The official numpy mingw binaries do not have all these math issues.
Only the VC builds do.
As mingw is fine the functions must be somewhere in the windows API
but
no-one has contributed a fix for the VC builds to numpy yet.
I'm building with mingw-w64.
It looks like this works as expected from this test:
#include math.h
#include stdio.h
int main() {
double z;
z = expm1(-0.0);
printf(Result %f\n, z);
}
(prints -0).
as does this (modified from core/src/npymath/npy_math.c.src):
#include stdio.h
double npy_expm1(double x)
{
if (isinf(x) x 0) {
return x;
}
else {
const double u = exp(x);
if (u == 1.0) {
return x;
} else if (u - 1.0 == -1.0) {
return -1;
} else {
return (u - 1.0) * x/log(u);
}
}
}
int main() {
double z;
z = npy_expm1(-0.0);
printf(Result %f\n, z);
}
Sorry for my ignorance, but where does the `HAVE_EXPM1` symbol come
from?
Remember all configuration output at the beginning of the build? One of
those tries to link 'expm1{f, , l}' and sets the value of
'HAVE_EXPM1{F,,L}'
accordingly. You can find the result in the `config.h` file in the build
directory.
Ah - thanks - that got me going - somewhere.
I noticed that HAVE_EXPM1 is not defined in any of OSX, my Windows
build, Debian config.h - is that expected?
It's defined for me, gcc version 4.8.2 on fedora 20. I'm surprised that
Debian doesn't show it, what compiler version does Debian provide?
We could always borrow the boost version, although it uses the Kahan sum
for the series.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test error with ATLAS, Windows 64 bit
On Mon, Apr 14, 2014 at 5:01 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Mon, Apr 14, 2014 at 3:55 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Apr 14, 2014 at 4:40 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Mon, Apr 14, 2014 at 2:58 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Apr 14, 2014 at 3:38 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Mon, Apr 14, 2014 at 2:02 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
The official numpy mingw binaries do not have all these math issues.
Only the VC builds do.
As mingw is fine the functions must be somewhere in the windows API
but
no-one has contributed a fix for the VC builds to numpy yet.
I'm building with mingw-w64.
It looks like this works as expected from this test:
#include math.h
#include stdio.h
int main() {
double z;
z = expm1(-0.0);
printf(Result %f\n, z);
}
(prints -0).
as does this (modified from core/src/npymath/npy_math.c.src):
#include stdio.h
double npy_expm1(double x)
{
if (isinf(x) x 0) {
return x;
}
else {
const double u = exp(x);
if (u == 1.0) {
return x;
} else if (u - 1.0 == -1.0) {
return -1;
} else {
return (u - 1.0) * x/log(u);
}
}
}
int main() {
double z;
z = npy_expm1(-0.0);
printf(Result %f\n, z);
}
Sorry for my ignorance, but where does the `HAVE_EXPM1` symbol come
from?
Remember all configuration output at the beginning of the build? One of
those tries to link 'expm1{f, , l}' and sets the value of
'HAVE_EXPM1{F,,L}'
accordingly. You can find the result in the `config.h` file in the build
directory.
Ah - thanks - that got me going - somewhere.
I noticed that HAVE_EXPM1 is not defined in any of OSX, my Windows
build, Debian config.h - is that expected?
It's defined for me, gcc version 4.8.2 on fedora 20. I'm surprised that
Debian doesn't show it, what compiler version does Debian provide?
Yes, sorry - I had an old version of numpy on Debian. It is defined for 1.8.1
It's not defined on OSX because it is defined in pyconfig.h (via Python.h).
I was wrong, it is defined in config.h for Windows, I'm not sure how I
missed that. Now I'm trying to understand why it's giving different
results from the tiny test function above,
It looks as though mingw-w64 is at fault, and I was confused (still
am) because of the different behavior with double and a constant:
#include stdio.h
#include math.h
int main() {
double z, i = -0.0;
printf(With double %f=%f, with constant=%f\n,
i, expm1(i), expm1(-0.));
}
gives:
With double -0.00=0.00, with constant=-0.00
That was ugly to track down.
What is the right way to work round this (using the numpy version
instead of the system version I suppose)?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
