Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
Hi Chuck On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris charlesr.har...@gmail.com wrote: I'll bet the skimage problems come from https://github.com/numpy/numpy/pull/3811. They may be doing something naughty... Reverting that commit fixes those skimage failures. However, there are a number of python2.7 failures that look pretty strange. What is the exact change in behavior with that PR? I'm trying to figure out what skimage does wrong in this case. Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
Hi Stefan, On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt ste...@sun.ac.zawrote: Hi Chuck On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris charlesr.har...@gmail.com wrote: I'll bet the skimage problems come from https://github.com/numpy/numpy/pull/3811. They may be doing something naughty... Reverting that commit fixes those skimage failures. However, there are a number of python2.7 failures that look pretty strange. What is the exact change in behavior with that PR? I'm trying to figure out what skimage does wrong in this case. 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Wed, Oct 2, 2013 at 11:43 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi Stefan, On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt ste...@sun.ac.zawrote: Hi Chuck On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris charlesr.har...@gmail.com wrote: I'll bet the skimage problems come from https://github.com/numpy/numpy/pull/3811. They may be doing something naughty... Reverting that commit fixes those skimage failures. However, there are a number of python2.7 failures that look pretty strange. What is the exact change in behavior with that PR? I'm trying to figure out what skimage does wrong in this case. 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 So, just to be clear... what would happen if I had an array of floats between 0 and 1 inclusive and I cast that as a boolean using astype()? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Wed, Oct 2, 2013 at 10:12 AM, Benjamin Root ben.r...@ou.edu wrote: On Wed, Oct 2, 2013 at 11:43 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi Stefan, On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt ste...@sun.ac.zawrote: Hi Chuck On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris charlesr.har...@gmail.com wrote: I'll bet the skimage problems come from https://github.com/numpy/numpy/pull/3811. They may be doing something naughty... Reverting that commit fixes those skimage failures. However, there are a number of python2.7 failures that look pretty strange. What is the exact change in behavior with that PR? I'm trying to figure out what skimage does wrong in this case. 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 So, just to be clear... what would happen if I had an array of floats between 0 and 1 inclusive and I cast that as a boolean using astype()? You get zeros and ones. I don't think that has changed. Of course, you can still mess things up using views ;) Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke cgoh...@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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Tue, Oct 1, 2013 at 4:43 AM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke cgoh...@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?
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Tue, Oct 1, 2013 at 1:56 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Oct 1, 2013 at 4:43 AM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke cgoh...@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?
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.
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Tue, Oct 1, 2013 at 7:25 AM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Oct 1, 2013 at 1:56 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Oct 1, 2013 at 4:43 AM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Sep 30, 2013 at 10:51 PM, Christoph Gohlke cgoh...@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?
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.
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...
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Tue, Oct 1, 2013 at 4:41 PM, Pauli Virtanen p...@iki.fi wrote: Hi, 01.10.2013 16:28, Jack Howarth kirjoitti: [clip] /sw/bin/python2.7 setup.py build which fails at... /sw/bin/gfortran -Wall -L/sw/lib build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1 -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lgfortran -o build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so Undefined symbols for architecture x86_64: _main, referenced from: start in crt1.10.6.o [clip] Something is screwed up in your build environment: the `-shared` flag is missing from the link command. Perhaps you have set one of the the environment variables FFLAGS, CFLAGS, LDFLAGS? Also the `-undefined dynamic_lookup` flag. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Tue, Oct 1, 2013 at 5:02 PM, Jack Howarth howa...@bromo.med.uc.edu wrote: On Tue, Oct 01, 2013 at 04:52:06PM +0100, Robert Kern wrote: On Tue, Oct 1, 2013 at 4:41 PM, Pauli Virtanen p...@iki.fi wrote: Hi, 01.10.2013 16:28, Jack Howarth kirjoitti: [clip] /sw/bin/python2.7 setup.py build which fails at... /sw/bin/gfortran -Wall -L/sw/lib build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/sw/lib -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin10.8.0/4.8.1 -Lbuild/temp.macosx-10.6-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lgfortran -o build/lib.macosx-10.6-x86_64-2.7/numpy/linalg/lapack_lite.so Undefined symbols for architecture x86_64: _main, referenced from: start in crt1.10.6.o [clip] Something is screwed up in your build environment: the `-shared` flag is missing from the link command. Perhaps you have set one of the the environment variables FFLAGS, CFLAGS, LDFLAGS? Also the `-undefined dynamic_lookup` flag. The consensus of the fink developers is that you are introducing a bug in both scipy and numpy. The build should be able to pass additional flags on these variables and the scipy/numpy build should be able to append any additional flags required. In particular, both MacPorts and fink will want to be able to pass -L/opt/local/lib or -L/sw/lib via LDFLAGS. The changes added to scipy and numpy have broken this and now require that these additional flags be manually patched into the Makefiles of numpy and scipy rather than just passing them on LDFLAGS as has always worked in the past. Oh no it hasn't. It has been a consistent thorn in our side for a very long time. In the case of Fortran modules built by numpy.distutils, $LDFLAGS has replaced rather than appended flags since time immemorial. It is a compromise solution to work around the fact that the wide variety of Fortran compilers are very finicky about their flags, and distutils is not very accommodating about letting users change the flags to suit their local environments. If you think you have a better solution to this problem that does not degrade the existing flexibility, your PR will be cheerfully accepted. No one thinks this is desirable behavior, but it is most certainly not *new* behavior. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
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.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 ___ SciPy-Dev mailing list scipy-...@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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,
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Mon, Sep 30, 2013 at 4:45 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On 9/30/2013 3:45 PM, Charles R Harris wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 9/30/2013 3:45 PM, Charles R Harris wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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:
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On 01.10.2013 01:30, Charles R Harris wrote: On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 3:45 PM, Charles R Harris wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com mailto:charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On 9/30/2013 4:44 PM, Julian Taylor wrote: On 01.10.2013 01:30, Charles R Harris wrote: On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 3:45 PM, Charles R Harris wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com mailto:charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Mon, Sep 30, 2013 at 6:13 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 9/30/2013 4:44 PM, Julian Taylor wrote: On 01.10.2013 01:30, Charles R Harris wrote: On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 3:45 PM, Charles R Harris wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com mailto:charlesr.har...@gmail.com mailto: charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1
On Mon, Sep 30, 2013 at 6:37 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Sep 30, 2013 at 6:13 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 9/30/2013 4:44 PM, Julian Taylor wrote: On 01.10.2013 01:30, Charles R Harris wrote: On Mon, Sep 30, 2013 at 5:12 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 3:45 PM, Charles R Harris wrote: On Mon, Sep 30, 2013 at 3:51 PM, Christoph Gohlke cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu mailto:cgoh...@uci.edu wrote: On 9/30/2013 11:02 AM, Nathaniel Smith wrote: 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.har...@gmail.com mailto:charlesr.har...@gmail.com mailto: charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .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 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: ``` import numpy as np from pandas import Series s = Series([0.0]) result = np.nansum(s) print(result) Traceback (most recent call last): File stdin, line 1, in module File X:\Python33\lib\site-packages\pandas\core\base.py, line 19, in __str__ return self.__unicode__() File X:\Python33\lib\site-packages\pandas\core\series.py, line 1115, in __unicode__ length=len(self) 50, TypeError: len() of unsized object ``` 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
