Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm thinking of making a first release candidate this weekend. If you haven't yet tested the beta, please do so. It would be good to discover as many problems as we can before the first release.
Chuck
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm thinking of making a first release candidate this weekend. If you haven't yet tested the beta, please do so. It would be good to discover as many problems as we can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
Regards
Antoine.
On Wed, Aug 26, 2015 at 7:11 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
of making a first release candidate this weekend. If you haven't yet
tested
the beta, please do so. It would be good to discover as many problems as
we
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
The default casting mode has been changed. I think this has been raising a warning since 1.7 and was mentioned as a future change in 1.10, but you are right, it needs to be mentioned in the 1.10 release notes.
Chuck
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Aug 26, 2015 at 7:11 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
of making a first release candidate this weekend. If you haven't yet
tested
the beta, please do so. It would be good to discover as many problems
as we
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
The default casting mode has been changed. I think this has been raising a warning since 1.7 and was mentioned as a future change in 1.10, but you are right, it needs to be mentioned in the 1.10 release notes.
Make that warned of in the 1.9.0 release notes.
Chuck
On Wed, Aug 26, 2015 at 7:32 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Wed, Aug 26, 2015 at 7:11 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
of making a first release candidate this weekend. If you haven't yet
tested
the beta, please do so. It would be good to discover as many problems
as we
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
arr = np.linspace(0, 5, 10) out = np.empty_like(arr, dtype=np.intp) np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
The default casting mode has been changed. I think this has been raising a warning since 1.7 and was mentioned as a future change in 1.10, but you are right, it needs to be mentioned in the 1.10 release notes.
Make that warned of in the 1.9.0 release notes.
Here it is in 1.9.0 with deprecation warning made visible. ``` In [3]: import warnings
In [4]: warnings.simplefilter('always')
In [5]: arr = np.linspace(0, 5, 10)
In [6]: out = np.empty_like(arr, dtype=np.intp)
In [7]: np.round(arr, out=out) /home/charris/.local/lib/python2.7/site-packages/numpy/core/fromnumeric.py:2640: DeprecationWarning: Implicitly casting between incompatible kinds. In a future numpy release, this will raise an error. Use casting="unsafe" if this is intentional. return round(decimals, out) Out[7]: array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5]) ```
Chuck
Just a data point, I just tested 1.9.0rc1 (built from source) with matplotlib master, and things appear to be fine there. In fact, matplotlib was built against 1.7.x (I was hunting down a regression), and worked against the 1.9.0 install, so the ABI appears intact.
Cheers! Ben Root
On Wed, Aug 26, 2015 at 9:52 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Aug 26, 2015 at 7:32 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Wed, Aug 26, 2015 at 7:11 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
of making a first release candidate this weekend. If you haven't yet
tested
the beta, please do so. It would be good to discover as many problems
as we
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
> arr = np.linspace(0, 5, 10) > out = np.empty_like(arr, dtype=np.intp) > np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
> arr = np.linspace(0, 5, 10) > out = np.empty_like(arr, dtype=np.intp) > np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
> out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
The default casting mode has been changed. I think this has been raising a warning since 1.7 and was mentioned as a future change in 1.10, but you are right, it needs to be mentioned in the 1.10 release notes.
Make that warned of in the 1.9.0 release notes.
Here it is in 1.9.0 with deprecation warning made visible.
In [3]: import warnings In [4]: warnings.simplefilter('always') In [5]: arr = np.linspace(0, 5, 10) In [6]: out = np.empty_like(arr, dtype=np.intp) In [7]: np.round(arr, out=out) /home/charris/.local/lib/python2.7/site-packages/numpy/core/fromnumeric.py:2640: DeprecationWarning: Implicitly casting between incompatible kinds. In a future numpy release, this will raise an error. Use casting="unsafe" if this is intentional. return round(decimals, out) Out[7]: array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])Chuck
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Aug 26, 2015 7:03 PM, "Benjamin Root" ben.v.root@gmail.com wrote:
Just a data point, I just tested 1.9.0rc1 (built from source) with
matplotlib master, and things appear to be fine there. In fact, matplotlib was built against 1.7.x (I was hunting down a regression), and worked against the 1.9.0 install, so the ABI appears intact.
1.9, or 1.10?
-n
Aw, crap... I looked at the list of tags and saw the rc1... I'll test again in the morning.... Grumble, grumble... On Aug 26, 2015 10:53 PM, "Nathaniel Smith" njs@pobox.com wrote:
On Aug 26, 2015 7:03 PM, "Benjamin Root" ben.v.root@gmail.com wrote:
Just a data point, I just tested 1.9.0rc1 (built from source) with
matplotlib master, and things appear to be fine there. In fact, matplotlib was built against 1.7.x (I was hunting down a regression), and worked against the 1.9.0 install, so the ABI appears intact.
1.9, or 1.10?
-n
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi again,
The change seems to have possibly unforeseen consequences because some ufuncs don't declare all possible types, e.g.:
a = np.arange(10, dtype=np.int32) out = np.zeros_like(a) np.fabs(a, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: ufunc 'fabs' output (typecode 'd') could not be coerced to provided output parameter (typecode 'i') according to the casting rule ''same_kind''
np.fabs.types
['e->e', 'f->f', 'd->d', 'g->g', 'O->O']
(while fabs() wouldn't necessarily make sense on complex numbers, it does make sense on integers... and, ah, I've just noticed that np.abs() also exists with more input types, which is confusing...)
Regards
Antoine.
On Wed, 26 Aug 2015 07:52:09 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
On Wed, Aug 26, 2015 at 7:32 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Wed, Aug 26, 2015 at 7:11 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
of making a first release candidate this weekend. If you haven't yet
tested
the beta, please do so. It would be good to discover as many problems
as we
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
> arr = np.linspace(0, 5, 10) > out = np.empty_like(arr, dtype=np.intp) > np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
> arr = np.linspace(0, 5, 10) > out = np.empty_like(arr, dtype=np.intp) > np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
> out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
The default casting mode has been changed. I think this has been raising a warning since 1.7 and was mentioned as a future change in 1.10, but you are right, it needs to be mentioned in the 1.10 release notes.
Make that warned of in the 1.9.0 release notes.
Here it is in 1.9.0 with deprecation warning made visible.
In [3]: import warnings In [4]: warnings.simplefilter('always') In [5]: arr = np.linspace(0, 5, 10) In [6]: out = np.empty_like(arr, dtype=np.intp) In [7]: np.round(arr, out=out) /home/charris/.local/lib/python2.7/site-packages/numpy/core/fromnumeric.py:2640: DeprecationWarning: Implicitly casting between incompatible kinds. In a future numpy release, this will raise an error. Use casting="unsafe" if this is intentional. return round(decimals, out) Out[7]: array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])Chuck
The change also seems to have made datetime64 computations stricter:
np.datetime64('2010') - np.datetime64('2000-01-01')
numpy.timedelta64(3653,'D')
np.datetime64('2010') - np.datetime64('2000-01-01T00:00:00Z')
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Cannot cast ufunc subtract input from dtype('<M8[Y]') to dtype('<M8[s]') with casting rule 'same_kind'
Regards
Antoine.
On Wed, 26 Aug 2015 07:52:09 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
On Wed, Aug 26, 2015 at 7:32 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Wed, Aug 26, 2015 at 7:11 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris charlesr.harris@gmail.com wrote:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
of making a first release candidate this weekend. If you haven't yet
tested
the beta, please do so. It would be good to discover as many problems
as we
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find anything in the release notes, but see (1.10b1):
> arr = np.linspace(0, 5, 10) > out = np.empty_like(arr, dtype=np.intp) > np.round(arr, out=out)
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/antoine/np110/lib/python3.4/site-packages/numpy/core/fromnumeric.py", line 2778, in round_ return round(decimals, out) TypeError: ufunc 'rint' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
It used to work (1.9):
> arr = np.linspace(0, 5, 10) > out = np.empty_like(arr, dtype=np.intp) > np.round(arr, out=out)
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
> out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])
The default casting mode has been changed. I think this has been raising a warning since 1.7 and was mentioned as a future change in 1.10, but you are right, it needs to be mentioned in the 1.10 release notes.
Make that warned of in the 1.9.0 release notes.
Here it is in 1.9.0 with deprecation warning made visible.
In [3]: import warnings In [4]: warnings.simplefilter('always') In [5]: arr = np.linspace(0, 5, 10) In [6]: out = np.empty_like(arr, dtype=np.intp) In [7]: np.round(arr, out=out) /home/charris/.local/lib/python2.7/site-packages/numpy/core/fromnumeric.py:2640: DeprecationWarning: Implicitly casting between incompatible kinds. In a future numpy release, this will raise an error. Use casting="unsafe" if this is intentional. return round(decimals, out) Out[7]: array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])Chuck
Ok, I tested matplotlib master against numpy master, and there were no errors. I did get a bunch of new deprecation warnings though such as:
"/nas/home/broot/centos6/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/colorbar.py:539: VisibleDeprecationWarning: boolean index did not match indexed array along dimension 0; dimension is 5 but corresponding boolean dimension is 3 colors = np.asarray(colors)[igood]"
The message isn't exactly clear. I suspect the problem is a shape mismatch, like colors is 5x3, and igood is just 3 for some reason. Could somebody shine some light on this, please?
Ben Root
On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root ben.v.root@gmail.com wrote:
Ok, I tested matplotlib master against numpy master, and there were no errors. I did get a bunch of new deprecation warnings though such as:
"/nas/home/broot/centos6/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/colorbar.py:539: VisibleDeprecationWarning: boolean index did not match indexed array along dimension 0; dimension is 5 but corresponding boolean dimension is 3 colors = np.asarray(colors)[igood]"
The message isn't exactly clear. I suspect the problem is a shape mismatch, like colors is 5x3, and igood is just 3 for some reason. Could somebody shine some light on this, please?
IIRC, Boolean indexing would fill out the dimension, i.e., len 3 would be expanded to len 5 in this case. That behavior is deprecated.
Chuck
On Do, 2015-08-27 at 08:04 -0600, Charles R Harris wrote:
On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root ben.v.root@gmail.com wrote:
Ok, I tested matplotlib master against numpy master, and there were no errors. I did get a bunch of new deprecation warnings though such as: "/nas/home/broot/centos6/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/colorbar.py:539: VisibleDeprecationWarning: boolean index did not match indexed array along dimension 0; dimension is 5 but corresponding boolean dimension is 3 colors = np.asarray(colors)[igood]" The message isn't exactly clear. I suspect the problem is a shape mismatch, like colors is 5x3, and igood is just 3 for some reason. Could somebody shine some light on this, please?IIRC, Boolean indexing would fill out the dimension, i.e., len 3 would be expanded to len 5 in this case. That behavior is deprecated.
Yes, this is exactly the case, you have something like:
arr = np.zeros((5, 3)) ind = np.array([True, False, False]) arr[ind, :]
and numpy nowadays thinks that such code is likely a bug (when the ind is shorter than arr it is somewhat OK, the other way around gets more creepy). If you have an idea of how to make the error message clearer, or objections to the change, I am happy to hear it!
- Sebastian
Chuck
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Ok, I just wanted to make sure I understood the issue before going bug hunting. Chances are, it has been a bug on our end for a while now. Just to make sure, is the following valid?
arr = np.zeros((5, 3)) ind = np.array([True, True, True, False, True]) arr[ind] # gives a 4x3 result
Running that at the REPL doesn't produce a warning, so i am guessing that it is valid.
Ben Root
On Thu, Aug 27, 2015 at 10:44 AM, Sebastian Berg <sebastian@sipsolutions.net
wrote:
On Do, 2015-08-27 at 08:04 -0600, Charles R Harris wrote:
On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root ben.v.root@gmail.com wrote:
Ok, I tested matplotlib master against numpy master, and there were no errors. I did get a bunch of new deprecation warnings though such as:"/nas/home/broot/centos6/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/colorbar.py:539: VisibleDeprecationWarning: boolean index did not match indexed array along dimension 0; dimension is 5 but corresponding boolean dimension is 3
colors = np.asarray(colors)[igood]" The message isn't exactly clear. I suspect the problem is a shape mismatch, like colors is 5x3, and igood is just 3 for some reason. Could somebody shine some light on this, please?IIRC, Boolean indexing would fill out the dimension, i.e., len 3 would be expanded to len 5 in this case. That behavior is deprecated.
Yes, this is exactly the case, you have something like:
arr = np.zeros((5, 3)) ind = np.array([True, False, False]) arr[ind, :]
and numpy nowadays thinks that such code is likely a bug (when the ind is shorter than arr it is somewhat OK, the other way around gets more creepy). If you have an idea of how to make the error message clearer, or objections to the change, I am happy to hear it!
- Sebastian
Chuck
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Do, 2015-08-27 at 11:15 -0400, Benjamin Root wrote:
Ok, I just wanted to make sure I understood the issue before going bug hunting. Chances are, it has been a bug on our end for a while now. Just to make sure, is the following valid?
arr = np.zeros((5, 3))
ind = np.array([True, True, True, False, True])
arr[ind] # gives a 4x3 result
Running that at the REPL doesn't produce a warning, so i am guessing that it is valid.
Sure, that is perfect (you can add the slice and write `arr[ind, :]` to make it a bit more clear if you like I guess).
- Sebastian
Ben Root
On Thu, Aug 27, 2015 at 10:44 AM, Sebastian Berg sebastian@sipsolutions.net wrote: On Do, 2015-08-27 at 08:04 -0600, Charles R Harris wrote: > > > On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root ben.v.root@gmail.com > wrote: > > > Ok, I tested matplotlib master against numpy master, and there > were no errors. I did get a bunch of new deprecation warnings > though such as: > > "/nas/home/broot/centos6/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/colorbar.py:539: VisibleDeprecationWarning: boolean index did not match indexed array along dimension 0; dimension is 5 but corresponding boolean dimension is 3 > colors = np.asarray(colors)[igood]" > > > The message isn't exactly clear. I suspect the problem is a > shape mismatch, like colors is 5x3, and igood is just 3 for > some reason. Could somebody shine some light on this, please? > > > > IIRC, Boolean indexing would fill out the dimension, i.e., len 3 would > be expanded to len 5 in this case. That behavior is deprecated. >
Yes, this is exactly the case, you have something like: arr = np.zeros((5, 3)) ind = np.array([True, False, False]) arr[ind, :] and numpy nowadays thinks that such code is likely a bug (when the ind is shorter than arr it is somewhat OK, the other way around gets more creepy). If you have an idea of how to make the error message clearer, or objections to the change, I am happy to hear it! - Sebastian > > Chuck > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
The reason why we don't have that extra slice is because we may not know ahead of time that we are dealing with a 2D array. It could be a 1D array. I guess we could use ellipses, but I wanted to make sure that the numpy devs consider the above to be perfectly valid semantics because it is entrenched in our codebase.
Ben Root
On Thu, Aug 27, 2015 at 11:33 AM, Sebastian Berg <sebastian@sipsolutions.net
wrote:
On Do, 2015-08-27 at 11:15 -0400, Benjamin Root wrote:
Ok, I just wanted to make sure I understood the issue before going bug hunting. Chances are, it has been a bug on our end for a while now. Just to make sure, is the following valid?
arr = np.zeros((5, 3))
ind = np.array([True, True, True, False, True])
arr[ind] # gives a 4x3 result
Running that at the REPL doesn't produce a warning, so i am guessing that it is valid.
Sure, that is perfect (you can add the slice and write `arr[ind, :]` to make it a bit more clear if you like I guess).
- Sebastian
Ben Root
On Thu, Aug 27, 2015 at 10:44 AM, Sebastian Berg sebastian@sipsolutions.net wrote: On Do, 2015-08-27 at 08:04 -0600, Charles R Harris wrote: > > > On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root ben.v.root@gmail.com > wrote: > > > Ok, I tested matplotlib master against numpy master, and there > were no errors. I did get a bunch of new deprecation warnings > though such as: > >
"/nas/home/broot/centos6/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/colorbar.py:539: VisibleDeprecationWarning: boolean index did not match indexed array along dimension 0; dimension is 5 but corresponding boolean dimension is 3
> colors = np.asarray(colors)[igood]" > > > The message isn't exactly clear. I suspect the problem is a > shape mismatch, like colors is 5x3, and igood is just 3 for > some reason. Could somebody shine some light on this, please? > > > > IIRC, Boolean indexing would fill out the dimension, i.e., len 3 would > be expanded to len 5 in this case. That behavior is deprecated. > Yes, this is exactly the case, you have something like: arr = np.zeros((5, 3)) ind = np.array([True, False, False]) arr[ind, :] and numpy nowadays thinks that such code is likely a bug (when the ind is shorter than arr it is somewhat OK, the other way around gets more creepy). If you have an idea of how to make the error message clearer, or objections to the change, I am happy to hear it! - Sebastian > > Chuck > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (5)
-
Antoine Pitrou -
Benjamin Root -
Charles R Harris -
Nathaniel Smith -
Sebastian Berg