BUG: Fix handling of mixed-type arrays in histogram#7864
BUG: Fix handling of mixed-type arrays in histogram#7864zkillpack wants to merge 1 commit intonumpy:masterfrom
Conversation
|
Sorry, I'm having trouble figuring out what behavior you expect here. I would have expected that passing histogram an array containing another array would always be an error. Is that what you expect to? |
|
I decided to allow this rather than raise an error, given that single-element arrays implement enough interfaces for this to work, were it not for the bug. In any case, the current behavior is inconsistent: if the input is degenerate, it shouldn't allow it in some cases, and give an unexpected error in others. |
|
☔ The latest upstream changes (presumably #8584) made this pull request unmergeable. Please resolve the merge conflicts. |
|
To me, it feels like |
| raise ValueError( | ||
| 'max must be larger than min in range parameter.') | ||
| if not np.all(np.isfinite([mn, mx])): | ||
| if not np.all(np.isfinite(np.hstack([mn, mx]))): |
There was a problem hiding this comment.
This can of worms would be better solved with np.isfinite(mn) and np.isinfinite(mx)
Arrays that contain both floats and single-element float arrays behave inconsistently in np.histogram:
Running this works as expected:
Running this does not:
Similarly, this gives the expected result:
Running this does not:
Since arrays and floats both implement max() and min(), the bounds-checking code at the beginning of histogram() will happily take the max and min, and then inconsistently infer the dtype depending on the size of the array's contents, e.g.: