BUG: `.describe()` on `unsigned` types is resulting in `object` type result

[galipremsagar]

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

In [1]: import pandas as pd

In [2]: s= pd.Series([0, 1, 2, 3, 1, 2, 3])

In [3]: s
Out[3]: 
0    0
1    1
2    2
3    3
4    1
5    2
6    3
dtype: int64

In [4]: s.describe()
Out[4]: 
count    7.000000
mean     1.714286
std      1.112697
min      0.000000
25%      1.000000
50%      2.000000
75%      2.500000
max      3.000000
dtype: float64

In [5]: s.astype('uint64')
Out[5]: 
0    0
1    1
2    2
3    3
4    1
5    2
6    3
dtype: uint64

In [6]: s.astype('uint64').describe()
Out[6]: 
count           7
mean     1.714286
std      1.112697
min             0
25%           1.0
50%           2.0
75%           2.5
max             3
dtype: object

Issue Description

When there are unsigned integers in a series. The result of describe() call is returning a series of object dtype rather than float dtype. Not a pressing issue, but something must be going wrong that is resulting in an object dtype here.

Expected Behavior

Return a series with numeric dtypes.

Installed Versions

INSTALLED VERSIONS

commit : 224458e
python : 3.9.13.final.0
python-bits : 64
OS : Linux
OS-release : 4.15.0-76-generic
Version : #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.5.0rc0
numpy : 1.22.4
pytz : 2022.2.1
dateutil : 2.8.2
setuptools : 65.3.0
pip : 22.2.2
Cython : 0.29.32
pytest : 7.1.2
hypothesis : 6.54.4
sphinx : 5.1.1
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.9.1
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.2
IPython : 8.4.0
pandas_datareader: None
bs4 : 4.11.1
bottleneck : None
brotli :
fastparquet : None
fsspec : 2022.7.1
gcsfs : None
matplotlib : None
numba : 0.55.2
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 9.0.0
pyreadstat : None
pyxlsb : None
s3fs : 2022.7.1
scipy : 1.9.1
snappy :
sqlalchemy : 1.4.40
tables : None
tabulate : 0.8.10
xarray : None
xlrd : None
xlwt : None
zstandard : None
tzdata : None

[galipremsagar]

Note: This issue surfaced in pandas 1.5.rc0 and isn't present in previous versions of pandas.

[mroeschke]

Thanks a more minimal example:

In [1]: Series([np.int64(1), np.uint64(1)])
Out[1]:
0    1
1    1
dtype: object

This was the output in 1.4.3

>>> Series([np.int64(1), np.uint64(1)])
0    1
1    1
dtype: int64

[mroeschke]

@rhshadrach I see you added a test in #47475 where maybe_convert_objects(int32, uint32) -> object, so this might be intended behavior such that there would not be lossless casting to int64?

https://github.com/pandas-dev/pandas/pull/47475/files#diff-6fed538cd081868e928e58612c185d2358dcaccae23b4d6a503b9ff390b5a65cR723

[rhshadrach]

@mroeschke - that was done to be consistent with other cases where int and unsigned are combined to object; I do think int64 would be a better result; see #47673

Also, in this case we don't need to apply the inference rules used when passed a list of Python objects from the user. We could e.g. store the various results in a numpy float array and then convert to a Series. Or perhaps the object result is more desirable in this case? It's at least more readable in my opinion, and isn't that the primary use of describe?

[mroeschke]

Or perhaps the object result is more desirable in this case? It's at least more readable in my opinion, and isn't that the primary use of describe?

Ah true. I would agree that the new behavior is in theory nicer such value types are preserved (e.g. min/max can stay uint64 from the original type and don't get coerced to float just because the mean/std are float).

[phofl]

Adding 1.5 milestone for now so that we can keep track

[rhshadrach]

I believe this issue can be resolved by adding dtype=float to

pandas/pandas/core/describe.py

Line 243 in 78a5f71

return Series(d, index=stat_index, name=series.name)

The list of values includes the result of mean, which is always a float regardless of the value, and so this should be backwards compatible (i.e. prior to the change in inferring dtype that induced this regression).

Assuming no objections to this approach, I can put up a PR in the next day or two, but more than happy if someone else beats me to it.