BUG: Fix handling of mixed-type arrays in histogram #7864
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 |
| @@ -660,7 +660,7 @@ def histogram(a, bins=10, range=None, normed=False, weights=None, | |||
| if mn > mx: | |||
| 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.: