avoid use of deprecated numpy.bool alias #1485
Conversation
|
Hi! Welcome, and thanks for opening this pull request. We ask that you follow our template for new pull requests, and soon you'll hear back about the results of our tests and continuous integration checks. Thank you for your contribution! |
neutrinoceros
force-pushed
the
fix_numpy_bool
branch
from
03ed0d1
to
2ed3dcd
Compare
neutrinoceros
changed the title
| @@ -155,7 +156,7 @@ def __getitem__(self, key): | |||
| return getattr(mats[int(key)], name) | |||
| elif isinstance(key, slice): | |||
| return np.array([getattr(mats[i], name) for i in range(*key.indices(size))]) | |||
| elif isinstance(key, np.ndarray) and key.dtype == np.bool: | |||
| elif isinstance(key, np.ndarray) and key.dtype in _BOOLEAN_TYPES: | |||
There was a problem hiding this comment.
I believe that setting key.dtype == bool may be more efficient in this case. This comparison checks if the data type (dtype) of key is exactly bool. On the other hand, using key.dtype in (bool, np.bool_) checks if the dtype is either bool or np.bool_. This approach involves iterating over the elements of the tuple to find a match, which could potentially be slower.
There was a problem hiding this comment.
You are right that my proposed change would be technically slower, involving 2 equality checks instead of one, but note that
- we're talking 10s of nano-seconds here (hopefully this doesn't matter)
- because
boolis the first element in_BOOLEAN_TYPES, the second check is only performed in casekey.dtype != bool - if performance was important here (again, I'm hoping it's not),
key.dtype is boolwould be the way to go (identity check is always cheaper than equality check, although here it's 20ns VS 24ns on my machine)
There was a problem hiding this comment.
Considering the potential impact on simulation time when the code is called multiple times (considering large data), it becomes more important to optimize the comparison. In that case, using key.dtype == bool would be more efficient compared to key.dtype in (bool, np.bool_) due to the reduced number of operations involved. However, it's still advisable to measure the actual performance gain before making a decision, as the difference might still be minimal.
There was a problem hiding this comment.
Does the proposed approach ensure some kind of backward compatibility? Are there configurations that may use one vs the other? Or is bool always available so that any invocation will always work if we restrict to bool? Put another way, what's the benefit to this proposed approach?
There was a problem hiding this comment.
My approach is supposed to be 100% backward compatible. Additionally, it survives np.bool_ (current implementation doesn't)
|
Thanks @neutrinoceros |
|
Hooray! Congratulations on your first merged pull request! We hope we keep seeing you around! If you haven't already, consider joining our User's Group and our Development List. 🎆 |
Description
Fix a compatibility issue with numpy>=1.24 (similar to #1479)
Motivation and Context
np.boolwas an alias to builtinbool. This alias was deprecated in numpy 1.20 and was removed in numpy 1.24