Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

groupby.agg (first, last, min, etc...) returns incorrect results for uint64 columns #26310

Closed
toliwaga opened this issue May 7, 2019 · 3 comments

Comments

@toliwaga
Copy link

commented May 7, 2019

Code Sample, a copy-pastable example if possible

import pandas as pd
import numpy as np

df = pd.DataFrame({'x': 6903052872240755750, 'y': [1,2]})
print(df.groupby('y').agg({'x': 'first'}))
df.x = df.x.astype(np.uint64)
print(df.groupby('y').agg({'x': 'first'}))

Problem description

groupby.agg (first, last, min, etc...) returns incorrect results for uint64 columns

Expected Output

expect same results in both cases below:
x
y
1 6903052872240755750
2 6903052872240755750
x
y
1 6903052872240755712
2 6903052872240755712

Output of pd.show_versions()

[paste the output of pd.show_versions() here below this line]
INSTALLED VERSIONS

commit: None
python: 3.6.8.final.0
python-bits: 64
OS: Darwin
OS-release: 18.5.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8

pandas: 0.24.2
pytest: None
pip: 19.1
setuptools: 41.0.1
Cython: None
numpy: 1.16.3
scipy: 1.2.1
pyarrow: None
xarray: None
IPython: None
sphinx: None
patsy: None
dateutil: 2.8.0
pytz: 2019.1
blosc: None
bottleneck: None
tables: 3.5.1
numexpr: 2.6.9
feather: None
matplotlib: None
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml.etree: None
bs4: None
html5lib: None
sqlalchemy: None
pymysql: None
psycopg2: None
jinja2: None
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None
gcsfs: None

@WillAyd

This comment has been minimized.

Copy link
Member

commented May 7, 2019

Looks like there is coercion behind the scenes to float which is causing the precision loss.

Investigation and PRs would certainly be welcome

@jreback

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

this is a duplicate issue / have to search for it

@mahepe

This comment has been minimized.

Copy link
Contributor

commented May 12, 2019

@WillAyd is correct: It seems to happen on line 489 here:

elif is_integer_dtype(values):
# we use iNaT for the missing value on ints
# so pre-convert to guard this condition
if (values == iNaT).any():
values = ensure_float64(values)
else:
values = ensure_int64_or_float64(values)

uint64 won't convert to int64 so it's coerced to float64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.