New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: dimension discovery fails when mixing scalars and shape==(1,) arrays #15075
Comments
Cc @nschloe, who is against this type of thing and can link to their issue |
Thanks for CCing. Yep, this really looks like something I've been going on about. 😺 #10404 I would argue that creating an object array is the correct thing here. After all, you're putting a float and an array together. If you created a Python list, [0.25, np.array([0.3])] you'd expect the same thing: The first entry is a float, the second an array of length 1. It would be confusing if lists and np.arrays behaved differently here. Also, implicitly creating a dtype float array here would make it impossible to ever create a Most of the time, specifying
|
OK, closing. That PR would have made the recent NEP 34 changes (since reverted) less disruptive to scipy. |
For the record, you could do
NumPy ndarrays are very different from python lists. I would have no expectation that |
The "automation" is quite clear here I think: Always get the "lowest" data type that can capture all input values: numpy.array([1, 2]).dtype # int64
numpy.array([1, numpy.array(2)]).dtype # int64, array of rank 0 are basically scalars
numpy.array([1.0, 2]).dtype # float64
numpy.array([1, [2]]).dtype # O |
np.array([0.25, np.array([0.3])])
will fail to create a float array, the dtype will be object.This seems wrong to me, is it intentional?
The text was updated successfully, but these errors were encountered: