Repository navigation
BUG: excess precision when printing float32 values #71916
Description
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
import pandas as pd
print(pd.Series([100.1], dtype="float32"))Issue Description
Pandas does not make a difference in how it displays float32 and float64 values, resulting in excess precision:
>>> import pandas as pd
>>> s = pd.Series([100.1], dtype="float32"); s
0 100.099998
dtype: float32
>>> print(s.iloc[0]) # Print the raw numpy.float32
100.1
>>> s.to_numpy()
array([100.1], dtype=float32)Pandas prints 100.099998 while Numpy knows that it's a float32 and prints it as 100.1. I'm well aware that this may be working as intented because of the default 6-digits precision that Pandas uses. This works well for float64 but not so much for float32.
Note that this issue is specifically about printing the series (including Jupyter's pretty-printed table display) and is unrelated to conversions like s.to_list(). Also note that round() doesn't help, as the issue is really with the display of the underlying float32 value and round() doesn't change that:
>>> import pandas as pd
>>> pd.Series([100.1], dtype="float32").round(1)
0 100.099998
dtype: float32Expected Behavior
>>> import pandas as pd
>>> s = pd.Series([100.1], dtype="float32"); s
0 100.1
dtype: float32Installed Versions
Details
INSTALLED VERSIONS
commit : 3dcc6fb
python : 3.14.4
python-bits : 64
OS : Linux
OS-release : 6.6.87.2-microsoft-standard-WSL2
Version : #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025
machine : x86_64
processor :
byteorder : little
LC_ALL : None
LANG : C.UTF-8
LOCALE : C.UTF-8
pandas : 3.1.1
numpy : 2.5.2
dateutil : 2.9.0.post0
pip : None
Cython : None
sphinx : None
IPython : 9.12.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.3
bottleneck : None
fastparquet : None
fsspec : None
html5lib : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : None
matplotlib : 3.10.8
numba : None
numexpr : None
odfpy : None
openpyxl : 3.1.5
psycopg2 : None
pymysql : None
pyarrow : 25.0.1
pyiceberg : None
pyreadstat : None
pytest : 9.1.1
python-calamine : None
pytz : 2026.2
pyxlsb : None
s3fs : None
scipy : 1.17.1
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
qtpy : None
pyqt5 : None
Activity
Rudra-G-23 commentedon Nov 7, 2026
Hi, I'd be interested in working on this issue once it's triaged.
Before proceeding, could you clarify whether the preferred fix is to use the shortest round-trippable representation for
float32values or preserve the existingdisplay.precisionbehavior?I can work on the fix and add regression tests once the expected behavior is confirmed.
rhshadrach commentedon Nov 7, 2026
Thanks for the report. Previously this was fixed for conversion to string (#36451); agreed we shouldn't trip through float64 when printing out these values.
A PR to fix this should also fix the Float32 and float32[pyarrow] cases along with float32.
Rudra-G-23 commentedon Nov 8, 2026
/take
jdemeyer commentedon Nov 8, 2026
Probably a combination of both, something like:
display.precision, use that shortest decimal. Otherwise, printdisplay.precisionnumber of digits as before.Actually, why not all floats? The fix that I suggested above might as well be applied for
float64too. I don't expect it would make much difference in practice for the default precision, but it's good to be consistent.