BUG: Fix lost precision with common type of uint64/int64 #61679
Conversation
|
pre-commit.ci autofix |
simonjayhawkins
added
Bug
Dtype Conversions
pandas/core/dtypes/api.py
Outdated
| @@ -59,6 +60,7 @@ | |||
| "is_float", | |||
| "is_float_dtype", | |||
| "is_hashable", | |||
| "is_implicit_conversion_to_float64", | |||
There was a problem hiding this comment.
To fix the original issue, we shouldn't need to create a new function (and expose it as a public API)
|
I think this patch is more safe and provides better performance |
|
I test another fix that can be benefit for other issues (e.g #61688) without any changes |
pbrochart
changed the title
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
| @@ -404,6 +404,7 @@ Other API changes | |||
| - Index set operations (like union or intersection) will now ignore the dtype of | |||
| an empty ``RangeIndex`` or empty ``Index`` with object dtype when determining | |||
| the dtype of the resulting Index (:issue:`60797`) | |||
| - ``np_find_common_type`` will now return ``object`` for mixed ``int64`` and ``uint64`` dtypes to avoid precision lost (:issue:`61676`, :issue:`61688`) | |||
There was a problem hiding this comment.
Hi,
I'm just skimming issues so have not looked in detail.
By glancing through I see we are changing tested behavior. This sort of suggests intentional behavior and not a bug per se. If it is a longstanding behavior we may want to deprecate first as a breaking API change?
In pandas we normally want to avoid object type, I don't see any discussion that this is an agreed way forward?
|
Hi, Numpy documentation is not explicit about it but the API give the best compromise for this kind of types as it's a hardware limitation. |
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.