hi, as numpy 1.9 is going to be a relative hard upgrade as indexing changes expose a couple bugs in third party packages and the large amount of small little incompatibilities I will create a numpy 1.8.2 release tomorrow with a couple of important or hard to work around bugfixes. The most important bugfix is fixing the wrong result partition with multiple selections could produce if selections ended up in an equal range, see https://github.com/numpy/numpy/issues/4836 (if the crash is still unreproducable, help appreciated). the rest of the fixes are small ones listed below. If I have missed one or you consider one of the fixes to invasive for a bugfix release please speak up now. As the number of fixes is small I will skip a release candidate. Make fftpack._raw_fft threadsafe https://github.com/numpy/numpy/issues/4656 Prevent division by zero https://github.com/numpy/numpy/issues/650 Fix lack of NULL check in array_richcompare https://github.com/numpy/numpy/issues/4613 incorrect argument order to _copyto in in np.nanmax, np.nanmin https://github.com/numpy/numpy/issues/4628 Hold GIL for types with fields, fixes https://github.com/numpy/numpy/issues/4642 svd ufunc typo https://github.com/numpy/numpy/issues/4733 check alignment of strides for byteswap https://github.com/numpy/numpy/issues/4774 add missing elementsize alignment check for simd reductions https://github.com/numpy/numpy/issues/4853 ifort has issues with optimization flag /O2 https://github.com/numpy/numpy/issues/4602
Hi, On Mon, Aug 4, 2014 at 3:05 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
hi, as numpy 1.9 is going to be a relative hard upgrade as indexing changes expose a couple bugs in third party packages and the large amount of small little incompatibilities I will create a numpy 1.8.2 release tomorrow with a couple of important or hard to work around bugfixes.
The most important bugfix is fixing the wrong result partition with multiple selections could produce if selections ended up in an equal range, see https://github.com/numpy/numpy/issues/4836 (if the crash is still unreproducable, help appreciated).
the rest of the fixes are small ones listed below. If I have missed one or you consider one of the fixes to invasive for a bugfix release please speak up now. As the number of fixes is small I will skip a release candidate.
Make fftpack._raw_fft threadsafe https://github.com/numpy/numpy/issues/4656
Prevent division by zero https://github.com/numpy/numpy/issues/650
Fix lack of NULL check in array_richcompare https://github.com/numpy/numpy/issues/4613
incorrect argument order to _copyto in in np.nanmax, np.nanmin https://github.com/numpy/numpy/issues/4628
Hold GIL for types with fields, fixes https://github.com/numpy/numpy/issues/4642
svd ufunc typo https://github.com/numpy/numpy/issues/4733
check alignment of strides for byteswap https://github.com/numpy/numpy/issues/4774
add missing elementsize alignment check for simd reductions https://github.com/numpy/numpy/issues/4853
ifort has issues with optimization flag /O2 https://github.com/numpy/numpy/issues/4602
Any chance of a RC to give us some time to test? Cheers, Matthew
On 05.08.2014 00:09, Matthew Brett wrote:
Hi,
On Mon, Aug 4, 2014 at 3:05 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
hi, as numpy 1.9 is going to be a relative hard upgrade as indexing changes expose a couple bugs in third party packages and the large amount of small little incompatibilities I will create a numpy 1.8.2 release tomorrow with a couple of important or hard to work around bugfixes. ...
Any chance of a RC to give us some time to test?
I hope I have only selected fixes that are safe and do not require a RC. sure we could do one, but if there are issues we can also just make a quick 1.8.3 release follow up. the main backport PR is: https://github.com/numpy/numpy/pull/4949
On Mon, Aug 4, 2014 at 11:12 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 05.08.2014 00:09, Matthew Brett wrote:
Hi,
On Mon, Aug 4, 2014 at 3:05 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
hi, as numpy 1.9 is going to be a relative hard upgrade as indexing changes expose a couple bugs in third party packages and the large amount of small little incompatibilities I will create a numpy 1.8.2 release tomorrow with a couple of important or hard to work around bugfixes. ...
Any chance of a RC to give us some time to test?
I hope I have only selected fixes that are safe and do not require a RC. sure we could do one, but if there are issues we can also just make a quick 1.8.3 release follow up.
the main backport PR is: https://github.com/numpy/numpy/pull/4949
It's probably better to just make an RC if it's not too much trouble... it's always possible to misjudge what issues arise, if there's a real-but-non-catastrophic issue then people 1.8.2 will remain in use even if 1.8.3 is released afterwards and force downstream libraries to work around the issues, and just in general it's good to have and follow standard processes because special cases lead to errors. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Mon, Aug 4, 2014 at 3:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Aug 4, 2014 at 11:12 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 05.08.2014 00:09, Matthew Brett wrote:
Hi,
On Mon, Aug 4, 2014 at 3:05 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
hi, as numpy 1.9 is going to be a relative hard upgrade as indexing changes expose a couple bugs in third party packages and the large amount of small little incompatibilities I will create a numpy 1.8.2 release tomorrow with a couple of important or hard to work around bugfixes. ...
Any chance of a RC to give us some time to test?
I hope I have only selected fixes that are safe and do not require a RC. sure we could do one, but if there are issues we can also just make a quick 1.8.3 release follow up.
A few days to test would be fine, I'd prefer an RC too, Cheers, Matthew
On 05.08.2014 00:27, Matthew Brett wrote:
On Mon, Aug 4, 2014 at 3:25 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Aug 4, 2014 at 11:12 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 05.08.2014 00:09, Matthew Brett wrote:
Hi,
On Mon, Aug 4, 2014 at 3:05 PM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
hi, as numpy 1.9 is going to be a relative hard upgrade as indexing changes expose a couple bugs in third party packages and the large amount of small little incompatibilities I will create a numpy 1.8.2 release tomorrow with a couple of important or hard to work around bugfixes. ...
Any chance of a RC to give us some time to test?
I hope I have only selected fixes that are safe and do not require a RC. sure we could do one, but if there are issues we can also just make a quick 1.8.3 release follow up.
A few days to test would be fine, I'd prefer an RC too,
alright I'll make an RC tomorrow and planning for release this weekend then.
Hi Everyone, I'm a bit confused about the way numpy treats conditions and I'm hoping you can help. Starting from this array: x = np.array(x)
x array([1, 2, 3, 2, 1]) x == 1 array([ True, False, False, False, True], dtype=bool)
works as expected, but the following is horribly wrong:
x == 1 + x == 3 Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
I can live with that, but why do brackets solve this?
(x == 1) + (x == 3) array([ True, False, True, False, True], dtype=bool)
Which is the same result as
(x == 1) | (x == 3) array([ True, False, True, False, True], dtype=bool)
It gets a bit weirder:
(x == 1) + (x < 3) array([ True, True, False, True, True], dtype=bool)
but
True + True 2
Is this the way it's supposed to work? Since it's quite different from python's scalar types, perhaps the documentation should mention it more clearly (for example, why isn't "or" implemented as a piecewise or). cheers, Michael
On Wed, Oct 1, 2014 at 10:01 AM, Michael Clerx <cell@michaelclerx.com> wrote:
Hi Everyone,
I'm a bit confused about the way numpy treats conditions and I'm hoping you can help.
Starting from this array:
x = np.array(x)
x array([1, 2, 3, 2, 1]) x == 1 array([ True, False, False, False, True], dtype=bool)
works as expected, but the following is horribly wrong:
x == 1 + x == 3 Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
Python parses this expression as the following, due to operator precedence:
x == (1 + x) == 3
The repeated == == has a special meaning in Python. It gets translated to this:
(x == (1+x)) and (x == 3)
The `and` is the problem here because it tries to evaluate each part as a bool, which is forbidden for arrays (hence the ValueError).
I can live with that, but why do brackets solve this?
(x == 1) + (x == 3) array([ True, False, True, False, True], dtype=bool)
Which is the same result as
(x == 1) | (x == 3) array([ True, False, True, False, True], dtype=bool)
It gets a bit weirder:
(x == 1) + (x < 3) array([ True, True, False, True, True], dtype=bool)
but
True + True 2
Is this the way it's supposed to work? Since it's quite different from python's scalar types, perhaps the documentation should mention it more clearly
Yes. For most of the binary ufuncs, especially the ones that implement the standard arithmetic operators +-*/, we try to make sure that if both arguments are the same dtype, the output is also the same dtype and do not promote. I believe that there was some discussion about this in the past year or so, and it turns out that this is the desired semantics for addition over boolean matrices when you start implementing linear algebra. The Python `bool` object has other concerns, namely backwards compatibility with older versions of Python that just used `True = 1; False = 0`.
(for example, why isn't "or" implemented as a piecewise or).
Do you mean "or" the Python keyword? This is documented. http://docs.scipy.org/doc/numpy/reference/ufuncs.html#comparison-functions -- Robert Kern
Thanks! I'd been looking at the documentation here: http://docs.scipy.org/doc/numpy/reference/routines.logic.html I'd never have thought to look at the ufunc page. Perhaps the docs are written slightly too much from an experienced numpy'er point of view. For example, on the logic page np.any and all are listed first. I can see how they're the most important functions, but the first I'd look for are and or & not. Is there a strict protocol for editing the docs? On 10/01/2014 11:23 AM, Robert Kern wrote:
On Wed, Oct 1, 2014 at 10:01 AM, Michael Clerx <cell@michaelclerx.com> wrote:
Hi Everyone,
I'm a bit confused about the way numpy treats conditions and I'm hoping you can help.
Starting from this array:
x = np.array(x)
x array([1, 2, 3, 2, 1]) x == 1 array([ True, False, False, False, True], dtype=bool)
works as expected, but the following is horribly wrong:
x == 1 + x == 3 Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() Python parses this expression as the following, due to operator precedence:
x == (1 + x) == 3 The repeated == == has a special meaning in Python. It gets translated to this:
(x == (1+x)) and (x == 3) The `and` is the problem here because it tries to evaluate each part as a bool, which is forbidden for arrays (hence the ValueError).
I can live with that, but why do brackets solve this?
(x == 1) + (x == 3) array([ True, False, True, False, True], dtype=bool)
Which is the same result as
(x == 1) | (x == 3) array([ True, False, True, False, True], dtype=bool)
It gets a bit weirder:
(x == 1) + (x < 3) array([ True, True, False, True, True], dtype=bool)
but
True + True 2
Is this the way it's supposed to work? Since it's quite different from python's scalar types, perhaps the documentation should mention it more clearly Yes. For most of the binary ufuncs, especially the ones that implement the standard arithmetic operators +-*/, we try to make sure that if both arguments are the same dtype, the output is also the same dtype and do not promote. I believe that there was some discussion about this in the past year or so, and it turns out that this is the desired semantics for addition over boolean matrices when you start implementing linear algebra. The Python `bool` object has other concerns, namely backwards compatibility with older versions of Python that just used `True = 1; False = 0`.
(for example, why isn't "or" implemented as a piecewise or). Do you mean "or" the Python keyword? This is documented.
http://docs.scipy.org/doc/numpy/reference/ufuncs.html#comparison-functions
On Wed, Oct 1, 2014 at 3:43 AM, Michael Clerx <cell@michaelclerx.com> wrote:
Thanks!
I'd been looking at the documentation here:
http://docs.scipy.org/doc/numpy/reference/routines.logic.html
I'd never have thought to look at the ufunc page. Perhaps the docs are written slightly too much from an experienced numpy'er point of view. For example, on the logic page np.any and all are listed first. I can see how they're the most important functions, but the first I'd look for are and or & not.
Is there a strict protocol for editing the docs?
Just make an ordinary pull request. See doc/source/dev/gitwash/development_workflow.rst <snip> Chuck
participants (6)
-
Charles R Harris -
Julian Taylor -
Matthew Brett -
Michael Clerx -
Nathaniel Smith -
Robert Kern