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:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris <charlesr.harris@gmail.com> wrote: 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:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris <charlesr.harris@gmail.com> wrote: 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:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris <charlesr.harris@gmail.com> wrote: 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:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris <charlesr.harris@gmail.com> wrote: 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:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris <charlesr.harris@gmail.com> wrote: 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:
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
On Tue, 25 Aug 2015 10:26:02 -0600 Charles R Harris <charlesr.harris@gmail.com> wrote: 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