Discussion:
[Numpy-discussion] 1.10.0rc1
Charles R Harris
2015-08-25 16:26:02 UTC
Permalink
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
Antoine Pitrou
2015-08-26 13:11:41 UTC
Permalink
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
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
Post by Charles R Harris
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''
Post by Charles R Harris
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])
Post by Charles R Harris
out
array([0, 1, 1, 2, 2, 3, 3, 4, 4, 5])


Regards

Antoine.
Charles R Harris
2015-08-26 13:31:45 UTC
Permalink
Post by Antoine Pitrou
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
Post by Charles R Harris
of making a first release candidate this weekend. If you haven't yet
tested
Post by Charles R Harris
the beta, please do so. It would be good to discover as many problems as
we
Post by Charles R Harris
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find
Post by Charles R Harris
arr = np.linspace(0, 5, 10)
out = np.empty_like(arr, dtype=np.intp)
np.round(arr, out=out)
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''
Post by Charles R Harris
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])
Post by Charles R Harris
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
Charles R Harris
2015-08-26 13:32:30 UTC
Permalink
Post by Charles R Harris
Post by Antoine Pitrou
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
Post by Charles R Harris
of making a first release candidate this weekend. If you haven't yet
tested
Post by Charles R Harris
the beta, please do so. It would be good to discover as many problems
as we
Post by Charles R Harris
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find
Post by Charles R Harris
arr = np.linspace(0, 5, 10)
out = np.empty_like(arr, dtype=np.intp)
np.round(arr, out=out)
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''
Post by Charles R Harris
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])
Post by Charles R Harris
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
Charles R Harris
2015-08-26 13:52:09 UTC
Permalink
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris <
Post by Charles R Harris
Post by Antoine Pitrou
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
Post by Charles R Harris
of making a first release candidate this weekend. If you haven't yet
tested
Post by Charles R Harris
the beta, please do so. It would be good to discover as many problems
as we
Post by Charles R Harris
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find
Post by Charles R Harris
arr = np.linspace(0, 5, 10)
out = np.empty_like(arr, dtype=np.intp)
np.round(arr, out=out)
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''
Post by Charles R Harris
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])
Post by Charles R Harris
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
Benjamin Root
2015-08-27 01:59:43 UTC
Permalink
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 7:32 AM, Charles R Harris <
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris <
Post by Charles R Harris
Post by Antoine Pitrou
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
Post by Charles R Harris
of making a first release candidate this weekend. If you haven't yet
tested
Post by Charles R Harris
the beta, please do so. It would be good to discover as many problems
as we
Post by Charles R Harris
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find
Post by Charles R Harris
arr = np.linspace(0, 5, 10)
out = np.empty_like(arr, dtype=np.intp)
np.round(arr, out=out)
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''
Post by Charles R Harris
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])
Post by Charles R Harris
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)
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
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Nathaniel Smith
2015-08-27 02:52:53 UTC
Permalink
Post by Benjamin Root
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
Benjamin Root
2015-08-27 03:01:55 UTC
Permalink
Aw, crap... I looked at the list of tags and saw the rc1... I'll test again
in the morning.... Grumble, grumble...
Post by Benjamin Root
Post by Benjamin Root
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
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Antoine Pitrou
2015-08-27 10:44:33 UTC
Permalink
Hi again,

The change seems to have possibly unforeseen consequences because some
Post by Charles R Harris
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''
Post by Charles R Harris
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
Post by Charles R Harris
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris <
Post by Antoine Pitrou
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
Post by Charles R Harris
of making a first release candidate this weekend. If you haven't yet
tested
Post by Charles R Harris
the beta, please do so. It would be good to discover as many problems
as we
Post by Charles R Harris
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find
Post by Charles R Harris
arr = np.linspace(0, 5, 10)
out = np.empty_like(arr, dtype=np.intp)
np.round(arr, out=out)
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''
Post by Charles R Harris
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])
Post by Charles R Harris
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)
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
Antoine Pitrou
2015-08-27 11:44:24 UTC
Permalink
Post by Charles R Harris
np.datetime64('2010') - np.datetime64('2000-01-01')
numpy.timedelta64(3653,'D')
Post by Charles R Harris
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
Post by Charles R Harris
On Wed, Aug 26, 2015 at 7:31 AM, Charles R Harris <
Post by Antoine Pitrou
On Tue, 25 Aug 2015 10:26:02 -0600
Post by Charles R Harris
Hi All,
The silence after the 1.10 beta has been eerie. Consequently, I'm
thinking
Post by Charles R Harris
of making a first release candidate this weekend. If you haven't yet
tested
Post by Charles R Harris
the beta, please do so. It would be good to discover as many problems
as we
Post by Charles R Harris
can before the first release.
Has typing of ufunc parameters become much stricter? I can't find
Post by Charles R Harris
arr = np.linspace(0, 5, 10)
out = np.empty_like(arr, dtype=np.intp)
np.round(arr, out=out)
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''
Post by Charles R Harris
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])
Post by Charles R Harris
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)
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
Benjamin Root
2015-08-27 13:52:31 UTC
Permalink
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
Charles R Harris
2015-08-27 14:04:51 UTC
Permalink
Post by Benjamin Root
Ok, I tested matplotlib master against numpy master, and there were no
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
Sebastian Berg
2015-08-27 14:44:34 UTC
Permalink
Post by Benjamin Root
Ok, I tested matplotlib master against numpy master, and there
were no errors. I did get a bunch of new deprecation warnings
"/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
Post by Benjamin Root
Chuck
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Benjamin Root
2015-08-27 15:15:40 UTC
Permalink
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
Post by Benjamin Root
Post by Benjamin Root
Ok, I tested matplotlib master against numpy master, and there
were no errors. I did get a bunch of new deprecation warnings
VisibleDeprecationWarning: boolean index did not match indexed array along
dimension 0; dimension is 5 but corresponding boolean dimension is 3
Post by Benjamin Root
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.
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
Post by Benjamin Root
Chuck
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Sebastian Berg
2015-08-27 15:33:16 UTC
Permalink
Post by Benjamin Root
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
Post by Benjamin Root
Ben Root
On Thu, Aug 27, 2015 at 10:44 AM, Sebastian Berg
On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root
Ok, I tested matplotlib master against numpy master,
and there
were no errors. I did get a bunch of new deprecation
warnings
"/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.
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
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Benjamin Root
2015-08-27 15:49:22 UTC
Permalink
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
Post by Sebastian Berg
Post by Benjamin Root
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
Post by Benjamin Root
Ben Root
On Thu, Aug 27, 2015 at 10:44 AM, Sebastian Berg
On Thu, Aug 27, 2015 at 7:52 AM, Benjamin Root
Ok, I tested matplotlib master against numpy master,
and there
were no errors. I did get a bunch of new deprecation
warnings
VisibleDeprecationWarning: boolean index did not match indexed array along
dimension 0; dimension is 5 but corresponding boolean dimension is 3
Post by Benjamin Root
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.
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
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Loading...