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: timedelta and float promotion sometimes works #16566
Comments
Looks like at least np.multiply supports this.
I think the above should also be considered a bug. |
I think the question is it always true that for ufuncs "casting rules are implemented by the question of when a data type can be cast “safely” to another data type" as described in the documentation. Looks like there are exceptions like above where casting isnt safe but we have made the ufunc to work. I guess in this case the promote_types should still say invalid type promotion (for both np.promote_types("float32", "m8") and np.promote_types("m8", "float32")). Whether we need to continue to allow ufunc to work can be decided on a case by case basis ? |
Yes, we have to clearly distinguish that Each ufunc individually can decide to implement a specific operation using "common dtype" or other logic. We specifically do it for multiple and timedelta64, so that is a separate issue indeed. I suppose we do not actually use this logic in many places, since ufuncs mostly rely on |
Given the above discussion I went ahead and added the fix for promote_types. |
The following examples do not lead to symmetric results:
The same is true for all other floating point types. I wonder if there is some strange logic to this, as a hack to allow certain ufunc calls, but I did not find one yet.
The text was updated successfully, but these errors were encountered: