BUG: to_numeric loses precision when converting decimal type to integer

[sfc-gh-aalam]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

from decimal import *
import pandas as pd

df = pd.DataFrame({'column1': [Decimal('1'*19)]})
print(pd.to_numeric(df['column1'], downcast='integer'))
print(df['column1'].astype('int64'))

"""
0    1111111111111111168
Name: column1, dtype: int64
0    1111111111111111111
Name: column1, dtype: int64
"""

Issue Description

When converting data from decimal type to integer using to_numeric, we see loss of precision where as doing the same conversion using astype('int64') works as expected without any precision loss.

Expected Behavior

Perform the conversion without a precision loss

Installed Versions

INSTALLED VERSIONS

commit : fd3f571
python : 3.9.16.final.0
python-bits : 64
OS : Darwin
OS-release : 23.2.0
Version : Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.2.0
numpy : 1.24.2
pytz : 2022.7.1
dateutil : 2.8.2
setuptools : 65.6.3
pip : 23.0.1
Cython : 0.29.34
pytest : None
hypothesis : None
sphinx : 5.0.2
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.2
IPython : None
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.8.2
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 10.0.1
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.11.2
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.4
qtpy : None
pyqt5 : None

[rhshadrach]

Thanks for the report. We likely go through float64. Further investigations and PRs to fix are welcome!

[Leventide]

I'll be attempting this.

[Leventide]

take