BUG: Fix lost precision with common type of uint64/int64
- [x] closes #61676  (Replace xxxx with the GitHub issue number)
- [x] closes #61688  (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

pre-commit.ci autofix 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
But it breaks some tests (the fix changes the behavior of np_find_common_type) pre-commit.ci autofix 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.
IIRC the precision start to lose if the uint64 number is above 2^53.
The API should not be deprecated in my opinion but rather be aware of this limitation.
I don't see any other solution than using an object. > I don't see any other solution than using an object.

there is another PR open to address the issue #61694. The approach there is to raise a ValueError instead. 