![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, NumPy 1.8.0rc1 is up now on sourceforge<http://sourceforge.net/projects/numpy/files/NumPy/1.8.0rc1/>.The binary builds are included except for Python 3.3 on windows, which will arrive later. Many thanks to Ralf for the binaries, and to those who found and fixed the bugs in the last beta. Any remaining bugs are all my fault ;) I hope this will be the last release before final, so please test it thoroughly. Chuck
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 10:21 AM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:
I was planning on that right after 1.8 is done. I still need to backport your little cpp fixes, the changes since 1.7 make that a bit tricky. Then there is checking for other missing backports... Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
Everyone please do actually test this! It is really in your best interest, and I think people don't always realize this. Here's how it works: - If you test it *now*, and it breaks your code that worked with 1.7, and you *tell* us this now, then it's *our* problem and we hold up the release to fix the bug. - If you test it *after* we release, and it breaks your code, then we are sad but you have to work around it (because we can't magically make that release not have happened, your users will be using it anyway), and we put it on the stack with all the other bugs. All of which we care about but it's a large enough stack that it's not going to get any special priority, because, see above about how at this point you'll have had to work around it anyway. -n On Mon, Sep 30, 2013 at 4:17 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 11:02 AM, Nathaniel Smith wrote:> Everyone please do actually test this! It is really in your best
Hello, NumPy 1.8.0rc1 looks good. All tests pass on Windows and most 3rd party packages test OK now. Thank you. A few tests still fail in the following packages when run with numpy-MKL-1.8.0rc1-win-amd64-py3.3 compared to numpy-MKL-1.7.1-win-amd64-py3.3: 1) Pandas 0.12.0 ``` ====================================================================== FAIL: test_nansum_buglet (pandas.tests.test_series.TestNanops) ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\pandas\tests\test_series.py", line 254, in test_nansum_buglet assert_almost_equal(result, 1) File "X:\Python33\lib\site-packages\pandas\util\testing.py", line 134, in assert_almost_equal np.testing.assert_(isiterable(b)) File "D:\Dev\Compile\Test\numpy-build\numpy\testing\utils.py", line 44, in assert_ raise AssertionError(msg) AssertionError ``` Possibly related: ```
2) Bottleneck 0.7.0
https://github.com/kwgoodman/bottleneck/issues/71#issuecomment-25331701
3) skimage 0.8.2
These tests passed with numpy 1.8.0b2:
====================================================================== FAIL: test_grey.test_non_square_image ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 162, in test_non_square_image testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 50.6328125%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, False, False], [ True, True, True, ..., False, False, False], [ True, True, True, ..., False, False, False],... ====================================================================== FAIL: test_grey.test_binary_erosion ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 169, in test_binary_erosion testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 48.260498046875%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, False, False], [ True, True, True, ..., False, False, False], [ True, True, True, ..., False, False, False],... ====================================================================== FAIL: test_grey.test_binary_closing ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 183, in test_binary_closing testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 66.302490234375%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, True, True], [ True, True, True, ..., True, True, True], [ True, True, True, ..., False, False, False],... ====================================================================== FAIL: test_grey.test_binary_opening ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 190, in test_binary_opening testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 58.465576171875%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, True, False], [ True, True, True, ..., True, True, False], [ True, True, True, ..., False, False, False],... ``` Christoph
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
I'll bet the skimage problems come from https://github.com/numpy/numpy/pull/3811. They may be doing something naughty... Chuck
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi Stefan, On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt <stefan@sun.ac.za>wrote:
The current master, and reverted for the 1.8 release only, is stricter about np.bool only taking values 0 or 1. Apparently the convolve returns boolean (I haven't checked) for boolean input, and consequently the check if the return value matches the number of 1 elements in the convolution kernel will fail when that number is greater than one. That is why the proposed fix is to view the boolean as uint8 instead. Note that out=(boolean) will still cause problems. Chuck
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 3:45 PM, Charles R Harris wrote:
A bool image is convolved with a uint8 kernel and the result compared for equality with an uint32 scalar... https://github.com/scikit-image/scikit-image/blob/master/skimage/morphology/... Christoph
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
Looks like the result of the convolution is probably output as a bool, which now means 0,1, which does not work when checking equality with the number of pixels in the kernel. I'd call expressing the result of a convolution as a boolean very naughty. Chuck
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 4:44 PM, Julian Taylor wrote:
I opened an issue at <https://github.com/scikit-image/scikit-image/issues/745> Christoph
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 6:13 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
The errors in skimage for Python 2.7 are also present for numpy 1.7.1. Maybe I'm missing some dependencies? A bunch of tests are skipped for Python 3.3 and I suspect the failing tests are among them. Chuck
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 6:37 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
The pandas test passes for current pandas dev, so it looks like a bug on their end that has been taken care of. test_nansum_buglet (__main__.TestNanops) ... ok Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 3:27 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
I'm concerned about this. 0.12.0 is currently the latest pandas release, so even if it is a bug on their side, we're going to be converting it from a latent bug to a real bug when we release... CC'ing pydata, do you guys have any insight into what changed here? The code is: s = pandas.Series([1.0, np.nan]) result = np.nansum(s) With numpy 1.7.1, 'result' comes out as a np.float64. With numpy maintenance/1.8.x, 'result' comes out as a 0-d Series object. Series is a subclass of ndarray, but it's supposed to always be 1-d, so all kinds of stuff blows up as soon as you have a 0-d Series object. I'm not sure what changed in numpy's nansum; if I try this same test with a simple no-op ndarray subclass: class MyArray(np.ndarray): pass np.nansum(np.array([1.0, np.nan]).view(MyArray)) then 1.7.1 and maintenance/1.8.x both act the same, and both return a 0-d MyArray, so it's not just a question of whether we remembered to handle subclasses at all. -n
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
2) Bottleneck 0.7.0
https://github.com/kwgoodman/bottleneck/issues/71#issuecomment-25331701
I can't tell if these are real bugs in numpy, or tests checking that bottleneck is bug-for-bug compatible with old numpy and we just fixed some bugs, or what. It's clearly something to do with the nanarg{max,min} rewrite -- @charris, do you know what's going on here? -n
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 4:43 AM, Nathaniel Smith <njs@pobox.com> wrote:
Yes ;) The previous behaviour of nanarg for all-nan axis was to cast nan to intp when the result was an array, and return nan when a scalar. The current behaviour is to return the most negative value of intp as an error marker in both cases and raise a warning. It is a change in behavior, but I think one that needs to be made. Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 1:56 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Ah, okay! I kind of lost track of the nanfunc changes by the end there. So for the bottleneck issue, it sounds like the problem is just that bottleneck is still emulating the old numpy behaviour in this corner case, which isn't really a problem. So we don't really need to worry about that, both behaviours are correct, just maybe out of sync. I'm a little dubious about this "make up some weird value that will *probably* blow up if people try to use it without checking, and also raise a warning" thing, wouldn't it make more sense to just raise an error? That's what exceptions are for? I guess I should have said something earlier though... -n
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 7:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
I figure the blowup is safe, as we can't allocate arrays big enough that the minimum intp value would be a valid index. I considered raising an error, and if there is a consensus the behavior could be changed. Or we could add a keyword to determine the behavior. Chuck
![](https://secure.gravatar.com/avatar/968b818b9553fbf74f79cf4b1db725a2.jpg?s=120&d=mm&r=g)
Den 30-09-2013 17:17, Charles R Harris skrev:
I seems that solve() doesn't like arrays like zeros((3, 0)). I get this with 1.8.0rc1 on Ubuntu 13.04 and Python 2.7.4: Python 2.7.4 (default, Apr 19 2013, 18:32:33) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. line 380, in solve r = gufunc(a, b, signature=signature, extobj=extobj) ValueError: cannot remove a zero-sized axis from an iterator with 1.7.1 it works OK:
Jens Jørgen
Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 11:00 AM, Jens Jørgen Mortensen <jensj@fysik.dtu.dk> wrote:
I seems that solve() doesn't like arrays like zeros((3, 0)). I get this with 1.8.0rc1 on Ubuntu 13.04 and Python 2.7.4:
Yep, looks like a simple bug in the new gufunc stuff, thanks for catching it. Filed here: https://github.com/numpy/numpy/issues/3847 -n
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Tue, 2013-10-01 at 12:00 +0200, Jens Jørgen Mortensen wrote:
Hey, can you create an issue on github so I don't forget it? This needs another special case to handle with the new gufunc based code. (Added checks there recently to fix these, but the `K=0` one is missing). - Sebastian
![](https://secure.gravatar.com/avatar/18a30ce6d84de6ce5c11ce006d10f616.jpg?s=120&d=mm&r=g)
On 30 September 2013 17:17, Charles R Harris <charlesr.harris@gmail.com>wrote:
I installed it with # python setup.py install But something is wrong there: line 19, in <module> from numpy.testing.utils import \ File "/usr/lib64/python2.7/site-packages/numpy/testing/utils.py", line 12, in <module> from .nosetester import import_nose File "/usr/lib64/python2.7/site-packages/numpy/testing/nosetester.py", line 12, in <module> from numpy.compat import basestring ImportError: cannot import name basestring I am using Python27 on Fedora 19. $ gcc --version gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 8:17 AM, Charles R Harris wrote:
One more: Cython-0.19.1 fails relaxed_strides.test_one_sized with "ValueError: ndarray is not C-contiguous". Tested on numpy-MKL-1.8.0rc1-win-amd64-py2.7 and msvc9. https://github.com/cython/cython/blob/0.19.x/tests/memoryview/relaxed_stride... The relevant test output is attached. Christoph
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
This is a complicated issue to describe but i think the bottom line is that the test is just wonky here. the behaviour it's checking for is: wrong in old numpy, but we do it anyway (bug) wrong in current numpy without RELAXED_STRIDES, and we get it right (I.e. don't do it, fixed bug) correct in current numpy with RELAXED_STRIDES (and I think the test will pass if you build 1.8 this way?) (fixed bug again, since the definition of "correct" flipped) correct in future numpys (@seberg, does that look right?) I guess maybe we could go back and make sure it stays broken in 1.8, but it's probably not worth the trouble because this is such a corner case. Nothing real is going to break because of this AFAICT. -n On 2 Oct 2013 08:31, "Christoph Gohlke" <cgohlke@uci.edu> wrote:
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Wed, 2013-10-02 at 10:04 +0100, Nathaniel Smith wrote:
Sounds about right, but I did not yet look at the test exactly. The old numpy had some corner cases where the *not* relaxed strides were not enforced. I could imagine that the test was written to accommodate the relaxed strides, but runs through fine with the old behaviour, too. That said, if this is the case, this must be something like a size 1 array corner case, so I would agree with Nathaniel, that probably the test should just see whether relaxed strides is active or not and change behaviour accordingly. If this has to do with the Buffer protocol change we have to have a closer look if it might be breaking code out there. (even if the buffer protocol change is correct and this should be fixed on cythons end in that case) - Sebastian
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Wed, 2013-10-02 at 12:54 +0200, Sebastian Berg wrote:
OK, I had a look. And it is the 1-dimensional size-1 special case that was always "relaxed", but is not anymore. If anyone thinks this is a problem, we could re-add the special case (rethinking it, it is almost impossible to hurt, since the array has only one element). Otherwise, I think the test should check if numpy was compiled with relaxed strides, for more extensive tests this is necessary anyway. - Sebastian
![](https://secure.gravatar.com/avatar/9dd264b29f74586017047f00f5fde1c3.jpg?s=120&d=mm&r=g)
Charles R Harris <charlesr.harris@gmail.com> writes:
I have installed 1.0.8rc1 on Python 3.3.2 on Mac OS X Snow Leopard (10.6.8) from the binary installer http://ufpr.dl.sourceforge.net/project/numpy/NumPy/1.8.0rc1/numpy-1.8.0rc1-p... an the test fails with 20 errors. I have tried it also with installing from source but it also gives these erros (I haven't checked if the errors are the same bit for bit, but they were also 20). Here is the output of the test run. -- Piet van Oostrum <piet@vanoostrum.org> WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 10:21 AM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:
I was planning on that right after 1.8 is done. I still need to backport your little cpp fixes, the changes since 1.7 make that a bit tricky. Then there is checking for other missing backports... Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
Everyone please do actually test this! It is really in your best interest, and I think people don't always realize this. Here's how it works: - If you test it *now*, and it breaks your code that worked with 1.7, and you *tell* us this now, then it's *our* problem and we hold up the release to fix the bug. - If you test it *after* we release, and it breaks your code, then we are sad but you have to work around it (because we can't magically make that release not have happened, your users will be using it anyway), and we put it on the stack with all the other bugs. All of which we care about but it's a large enough stack that it's not going to get any special priority, because, see above about how at this point you'll have had to work around it anyway. -n On Mon, Sep 30, 2013 at 4:17 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 11:02 AM, Nathaniel Smith wrote:> Everyone please do actually test this! It is really in your best
Hello, NumPy 1.8.0rc1 looks good. All tests pass on Windows and most 3rd party packages test OK now. Thank you. A few tests still fail in the following packages when run with numpy-MKL-1.8.0rc1-win-amd64-py3.3 compared to numpy-MKL-1.7.1-win-amd64-py3.3: 1) Pandas 0.12.0 ``` ====================================================================== FAIL: test_nansum_buglet (pandas.tests.test_series.TestNanops) ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\pandas\tests\test_series.py", line 254, in test_nansum_buglet assert_almost_equal(result, 1) File "X:\Python33\lib\site-packages\pandas\util\testing.py", line 134, in assert_almost_equal np.testing.assert_(isiterable(b)) File "D:\Dev\Compile\Test\numpy-build\numpy\testing\utils.py", line 44, in assert_ raise AssertionError(msg) AssertionError ``` Possibly related: ```
2) Bottleneck 0.7.0
https://github.com/kwgoodman/bottleneck/issues/71#issuecomment-25331701
3) skimage 0.8.2
These tests passed with numpy 1.8.0b2:
====================================================================== FAIL: test_grey.test_non_square_image ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 162, in test_non_square_image testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 50.6328125%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, False, False], [ True, True, True, ..., False, False, False], [ True, True, True, ..., False, False, False],... ====================================================================== FAIL: test_grey.test_binary_erosion ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 169, in test_binary_erosion testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 48.260498046875%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, False, False], [ True, True, True, ..., False, False, False], [ True, True, True, ..., False, False, False],... ====================================================================== FAIL: test_grey.test_binary_closing ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 183, in test_binary_closing testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 66.302490234375%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, True, True], [ True, True, True, ..., True, True, True], [ True, True, True, ..., False, False, False],... ====================================================================== FAIL: test_grey.test_binary_opening ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "X:\Python33\lib\site-packages\skimage\morphology\tests\test_grey.py", line 190, in test_binary_opening testing.assert_array_equal(binary_res, grey_res) File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 718, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "X:\Python33\lib\site-packages\numpy\testing\utils.py", line 644, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 58.465576171875%) x: array([[False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False], [False, False, False, ..., False, False, False],... y: array([[ True, True, True, ..., True, True, False], [ True, True, True, ..., True, True, False], [ True, True, True, ..., False, False, False],... ``` Christoph
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
I'll bet the skimage problems come from https://github.com/numpy/numpy/pull/3811. They may be doing something naughty... Chuck
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi Stefan, On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt <stefan@sun.ac.za>wrote:
The current master, and reverted for the 1.8 release only, is stricter about np.bool only taking values 0 or 1. Apparently the convolve returns boolean (I haven't checked) for boolean input, and consequently the check if the return value matches the number of 1 elements in the convolution kernel will fail when that number is greater than one. That is why the proposed fix is to view the boolean as uint8 instead. Note that out=(boolean) will still cause problems. Chuck
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 3:45 PM, Charles R Harris wrote:
A bool image is convolved with a uint8 kernel and the result compared for equality with an uint32 scalar... https://github.com/scikit-image/scikit-image/blob/master/skimage/morphology/... Christoph
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
Looks like the result of the convolution is probably output as a bool, which now means 0,1, which does not work when checking equality with the number of pixels in the kernel. I'd call expressing the result of a convolution as a boolean very naughty. Chuck
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 4:44 PM, Julian Taylor wrote:
I opened an issue at <https://github.com/scikit-image/scikit-image/issues/745> Christoph
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 6:13 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
The errors in skimage for Python 2.7 are also present for numpy 1.7.1. Maybe I'm missing some dependencies? A bunch of tests are skipped for Python 3.3 and I suspect the failing tests are among them. Chuck
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 6:37 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
The pandas test passes for current pandas dev, so it looks like a bug on their end that has been taken care of. test_nansum_buglet (__main__.TestNanops) ... ok Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 3:27 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
I'm concerned about this. 0.12.0 is currently the latest pandas release, so even if it is a bug on their side, we're going to be converting it from a latent bug to a real bug when we release... CC'ing pydata, do you guys have any insight into what changed here? The code is: s = pandas.Series([1.0, np.nan]) result = np.nansum(s) With numpy 1.7.1, 'result' comes out as a np.float64. With numpy maintenance/1.8.x, 'result' comes out as a 0-d Series object. Series is a subclass of ndarray, but it's supposed to always be 1-d, so all kinds of stuff blows up as soon as you have a 0-d Series object. I'm not sure what changed in numpy's nansum; if I try this same test with a simple no-op ndarray subclass: class MyArray(np.ndarray): pass np.nansum(np.array([1.0, np.nan]).view(MyArray)) then 1.7.1 and maintenance/1.8.x both act the same, and both return a 0-d MyArray, so it's not just a question of whether we remembered to handle subclasses at all. -n
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke <cgohlke@uci.edu> wrote:
2) Bottleneck 0.7.0
https://github.com/kwgoodman/bottleneck/issues/71#issuecomment-25331701
I can't tell if these are real bugs in numpy, or tests checking that bottleneck is bug-for-bug compatible with old numpy and we just fixed some bugs, or what. It's clearly something to do with the nanarg{max,min} rewrite -- @charris, do you know what's going on here? -n
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 4:43 AM, Nathaniel Smith <njs@pobox.com> wrote:
Yes ;) The previous behaviour of nanarg for all-nan axis was to cast nan to intp when the result was an array, and return nan when a scalar. The current behaviour is to return the most negative value of intp as an error marker in both cases and raise a warning. It is a change in behavior, but I think one that needs to be made. Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 1:56 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Ah, okay! I kind of lost track of the nanfunc changes by the end there. So for the bottleneck issue, it sounds like the problem is just that bottleneck is still emulating the old numpy behaviour in this corner case, which isn't really a problem. So we don't really need to worry about that, both behaviours are correct, just maybe out of sync. I'm a little dubious about this "make up some weird value that will *probably* blow up if people try to use it without checking, and also raise a warning" thing, wouldn't it make more sense to just raise an error? That's what exceptions are for? I guess I should have said something earlier though... -n
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 7:25 AM, Nathaniel Smith <njs@pobox.com> wrote:
I figure the blowup is safe, as we can't allocate arrays big enough that the minimum intp value would be a valid index. I considered raising an error, and if there is a consensus the behavior could be changed. Or we could add a keyword to determine the behavior. Chuck
![](https://secure.gravatar.com/avatar/968b818b9553fbf74f79cf4b1db725a2.jpg?s=120&d=mm&r=g)
Den 30-09-2013 17:17, Charles R Harris skrev:
I seems that solve() doesn't like arrays like zeros((3, 0)). I get this with 1.8.0rc1 on Ubuntu 13.04 and Python 2.7.4: Python 2.7.4 (default, Apr 19 2013, 18:32:33) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. line 380, in solve r = gufunc(a, b, signature=signature, extobj=extobj) ValueError: cannot remove a zero-sized axis from an iterator with 1.7.1 it works OK:
Jens Jørgen
Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 11:00 AM, Jens Jørgen Mortensen <jensj@fysik.dtu.dk> wrote:
I seems that solve() doesn't like arrays like zeros((3, 0)). I get this with 1.8.0rc1 on Ubuntu 13.04 and Python 2.7.4:
Yep, looks like a simple bug in the new gufunc stuff, thanks for catching it. Filed here: https://github.com/numpy/numpy/issues/3847 -n
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Tue, 2013-10-01 at 12:00 +0200, Jens Jørgen Mortensen wrote:
Hey, can you create an issue on github so I don't forget it? This needs another special case to handle with the new gufunc based code. (Added checks there recently to fix these, but the `K=0` one is missing). - Sebastian
![](https://secure.gravatar.com/avatar/18a30ce6d84de6ce5c11ce006d10f616.jpg?s=120&d=mm&r=g)
On 30 September 2013 17:17, Charles R Harris <charlesr.harris@gmail.com>wrote:
I installed it with # python setup.py install But something is wrong there: line 19, in <module> from numpy.testing.utils import \ File "/usr/lib64/python2.7/site-packages/numpy/testing/utils.py", line 12, in <module> from .nosetester import import_nose File "/usr/lib64/python2.7/site-packages/numpy/testing/nosetester.py", line 12, in <module> from numpy.compat import basestring ImportError: cannot import name basestring I am using Python27 on Fedora 19. $ gcc --version gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
![](https://secure.gravatar.com/avatar/6c2496a73573bf0c9ac85f71db561475.jpg?s=120&d=mm&r=g)
On 9/30/2013 8:17 AM, Charles R Harris wrote:
One more: Cython-0.19.1 fails relaxed_strides.test_one_sized with "ValueError: ndarray is not C-contiguous". Tested on numpy-MKL-1.8.0rc1-win-amd64-py2.7 and msvc9. https://github.com/cython/cython/blob/0.19.x/tests/memoryview/relaxed_stride... The relevant test output is attached. Christoph
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
This is a complicated issue to describe but i think the bottom line is that the test is just wonky here. the behaviour it's checking for is: wrong in old numpy, but we do it anyway (bug) wrong in current numpy without RELAXED_STRIDES, and we get it right (I.e. don't do it, fixed bug) correct in current numpy with RELAXED_STRIDES (and I think the test will pass if you build 1.8 this way?) (fixed bug again, since the definition of "correct" flipped) correct in future numpys (@seberg, does that look right?) I guess maybe we could go back and make sure it stays broken in 1.8, but it's probably not worth the trouble because this is such a corner case. Nothing real is going to break because of this AFAICT. -n On 2 Oct 2013 08:31, "Christoph Gohlke" <cgohlke@uci.edu> wrote:
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Wed, 2013-10-02 at 10:04 +0100, Nathaniel Smith wrote:
Sounds about right, but I did not yet look at the test exactly. The old numpy had some corner cases where the *not* relaxed strides were not enforced. I could imagine that the test was written to accommodate the relaxed strides, but runs through fine with the old behaviour, too. That said, if this is the case, this must be something like a size 1 array corner case, so I would agree with Nathaniel, that probably the test should just see whether relaxed strides is active or not and change behaviour accordingly. If this has to do with the Buffer protocol change we have to have a closer look if it might be breaking code out there. (even if the buffer protocol change is correct and this should be fixed on cythons end in that case) - Sebastian
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Wed, 2013-10-02 at 12:54 +0200, Sebastian Berg wrote:
OK, I had a look. And it is the 1-dimensional size-1 special case that was always "relaxed", but is not anymore. If anyone thinks this is a problem, we could re-add the special case (rethinking it, it is almost impossible to hurt, since the array has only one element). Otherwise, I think the test should check if numpy was compiled with relaxed strides, for more extensive tests this is necessary anyway. - Sebastian
![](https://secure.gravatar.com/avatar/9dd264b29f74586017047f00f5fde1c3.jpg?s=120&d=mm&r=g)
Charles R Harris <charlesr.harris@gmail.com> writes:
I have installed 1.0.8rc1 on Python 3.3.2 on Mac OS X Snow Leopard (10.6.8) from the binary installer http://ufpr.dl.sourceforge.net/project/numpy/NumPy/1.8.0rc1/numpy-1.8.0rc1-p... an the test fails with 20 errors. I have tried it also with installing from source but it also gives these erros (I haven't checked if the errors are the same bit for bit, but they were also 20). Here is the output of the test run. -- Piet van Oostrum <piet@vanoostrum.org> WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]
participants (10)
-
Benjamin Root
-
Charles R Harris
-
Christoph Gohlke
-
Daπid
-
Jens Jørgen Mortensen
-
Julian Taylor
-
Nathaniel Smith
-
Piet van Oostrum
-
Sebastian Berg
-
Stéfan van der Walt