Re: [Numpy-discussion] Writing successful tests
On Mon, Apr 14, 2014 at 5:26 AM, m...@pagan.io wrote: Greetings, I'm working on an additional function for numpy/lib/twodim_base.py. I'm trying to add some tests for the new function, and numpy/lib/tests/test_twodim_base.py seems like the right place for them. My problem is travis-ci tells me my tests are no good. The error message I get on my local machine is: ValueError: no such test method in class '__main__.TestElementary': runTest Please copy-and-paste the whole error message. Can you point to your code somewhere and the travis-ci results? How are you running the test suite? `numpy.test()` is the right way to do so. Do not use `unittest.main()` or `python -m unittest ...` to run the numpy test suite. (TestElementary is the class I made to put my tests in). This error makes me think I need a to put in a function like def __init__(self, methodName=runTest): or maybe def runTest(self): somewhere. I don't see functions like this associated with any of the other classes in numpy/lib/tests/test_twodim_base.py though. You would never do so, no. numpy uses the `nose` test runner which does not need these. If you were using the standard unittest test collector, you would subclass `TestElementary` from `unittest.TestCase`, and that would provide the correct `__init__()` and `runTest()` methods. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] assert_equal(-0.0, 0.0) fails.
The test function numpy.testing.assert_equal fails when comparing -0.0 and 0.0: In [16]: np.testing.assert_equal(-0.0, 0.0) --- AssertionErrorTraceback (most recent call last) ipython-input-16-4063bd6da228 in module() 1 np.testing.assert_equal(-0.0, 0.0) /Users/warren/anaconda/lib/python2.7/site-packages/numpy/testing/utils.pyc in assert_equal(actual, desired, err_msg, verbose) 309 elif desired == 0 and actual == 0: 310 if not signbit(desired) == signbit(actual): -- 311 raise AssertionError(msg) 312 # If TypeError or ValueError raised while using isnan and co, just handle 313 # as before AssertionError: Items are not equal: ACTUAL: -0.0 DESIRED: 0.0 There is code that checks for this specific case, so this is intentional. But this is not consistent with how negative zeros in arrays are compared: In [22]: np.testing.assert_equal(np.array(-0.0), np.array(0.0)) # PASS In [23]: a = np.array([-0.0]) In [24]: b = np.array([0.0]) In [25]: np.testing.assert_array_equal(a, b) # PASS Is there a reason the values are considered equal in an array, but not when compared as scalars? Warren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] index partition
On 4/12/2014 5:20 PM, Alexander Belopolsky wrote: The set routines [1] are in this category and may help you deal with partitions, but I would recommend using boolean arrays instead. If you commonly deal with both a subset and a complement, set representation does not give you a memory advantage over a boolean mask. I take it that by a lack of a memory advantage you mean because boolean arrays are 8 bit representations. That makes sense. I find it rather more convenient to use boolean arrays, but I wonder if arrays of indexes might have other advantages (which would suggest using the set operations instead). In particular, might a[boolean_array] be slower that a[indexes]? (I'm just asking, not suggesting.) Thanks! Alan ___ 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] Dates and times and Datetime64 (again)
On Fri, Apr 11, 2014 at 4:58 PM, Stephan Hoyer sho...@gmail.com wrote:
On Fri, Apr 11, 2014 at 3:56 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Are we in a position to start looking at implementation? If so, it would
be useful to have a collection of test cases, i.e., typical uses with
specified results. That should also cover conversion from/(to?)
datetime.datetime.
yup -- tests are always good!
Indeed, my personal wish-list for np.datetime64 is centered much more on
robust conversion to/from native date objects, including comparison.
A good use case.
Here are some of my particular points of frustration (apologies for the
thread jacking!):
- NaT should have similar behavior to NaN when used for comparisons (i.e.,
comparisons should always be False).
make sense.
- You can't compare a datetime object to a datetime64 object.
that would be nice to have.
- datetime64 objects with high precision (e.g., ns) can't compare to
datetime objects.
That's a problem, but how do you think it should be handled? My thought is
that it should round to microseconds, and then compare -- kind of like
comparing float32 and float64...
Pandas has a very nice wrapper around datetime64 arrays that solves most
of these issues, but it would be nice to get much of that functionality in
core numpy,
yes -- it would -- but learning from pandas is certainly a good idea.
from numpy import datetime64
from datetime import datetime
print np.datetime64('NaT') np.datetime64('2011-01-01') # this should not
to true
print datetime(2010, 1, 1) np.datetime64('2011-01-01') # raises exception
print np.datetime64('2011-01-01T00:00', 'ns') datetime(2010, 1, 1) #
another exception
print np.datetime64('2011-01-01T00:00') datetime(2010, 1, 1) # finally
something works!
now to get them into proper unit tests
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
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] assert_equal(-0.0, 0.0) fails.
On Mon, Apr 14, 2014 at 1:09 PM, Warren Weckesser warren.weckes...@gmail.com wrote: The test function numpy.testing.assert_equal fails when comparing -0.0 and 0.0: In [16]: np.testing.assert_equal(-0.0, 0.0) --- AssertionErrorTraceback (most recent call last) ipython-input-16-4063bd6da228 in module() 1 np.testing.assert_equal(-0.0, 0.0) /Users/warren/anaconda/lib/python2.7/site-packages/numpy/testing/utils.pyc in assert_equal(actual, desired, err_msg, verbose) 309 elif desired == 0 and actual == 0: 310 if not signbit(desired) == signbit(actual): -- 311 raise AssertionError(msg) 312 # If TypeError or ValueError raised while using isnan and co, just handle 313 # as before AssertionError: Items are not equal: ACTUAL: -0.0 DESIRED: 0.0 There is code that checks for this specific case, so this is intentional. But this is not consistent with how negative zeros in arrays are compared: In [22]: np.testing.assert_equal(np.array(-0.0), np.array(0.0)) # PASS In [23]: a = np.array([-0.0]) In [24]: b = np.array([0.0]) In [25]: np.testing.assert_array_equal(a, b) # PASS Is there a reason the values are considered equal in an array, but not when compared as scalars? Unlikely to be intentional. I expect this was a fix to assert_equal that wasn't synced to assert_array_equal. Ralf ___ 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
