Describe the bug
groupby().sum() changes a uint64 input column to int64.
The input column remains uint64, but the result of the groupby aggregation is int64. This causes an unexpected dtype change and can result in schema mismatches when the aggregated result is expected to remain unsigned.
Steps/Code to reproduce bug
import cudf
df = cudf.DataFrame(
{
"key": [1, 1, 2],
"value": [10, 20, 30],
}
)
df["value"] = df["value"].astype("uint64")
print("Input dtype:")
print(df["value"].dtype)
result = df.groupby("key")["value"].sum()
print("Result dtype:")
print(result.dtype)
Output in my environment:
Input dtype:
uint64
Result dtype:
int64
The dtype can also be verified with:
assert df["value"].dtype == "uint64"
assert result.dtype == "uint64"
The second assertion fails because result.dtype is int64.
Expected behavior
I would expect groupby().sum() to preserve the unsigned integer dtype:
Input dtype:
uint64
Result dtype:
uint64
In particular, when the input column is uint64, the aggregation result should remain uint64 unless there is a documented reason for promoting it to a signed integer type.
Environment overview (please complete the following information)
- Environment location: Bare-metal
- Method of cuDF install: pip
Environment details
Please run and paste the output of:
26.08.00
Additional context
I encountered this while aggregating a uint64 column containing view counts.
The original Parquet column is uint64, and it is also uint64 after reading it into cuDF. The dtype changes only when applying the groupby sum:
Parquet uint64
↓
cuDF input uint64
↓
groupby().sum() int64
I have also observed the same behavior when performing a second groupby aggregation on an already aggregated uint64 column.
As a workaround, I currently cast the result back to uint64:
result = (
df.groupby("key")["value"]
.sum()
.reset_index()
.astype({"value": "uint64"})
)
This is particularly relevant when maintaining a consistent schema across dataframe engines, where the equivalent aggregation preserves uint64.
Describe the bug
groupby().sum()changes auint64input column toint64.The input column remains
uint64, but the result of the groupby aggregation isint64. This causes an unexpected dtype change and can result in schema mismatches when the aggregated result is expected to remain unsigned.Steps/Code to reproduce bug
Output in my environment:
The dtype can also be verified with:
The second assertion fails because
result.dtypeisint64.Expected behavior
I would expect
groupby().sum()to preserve the unsigned integer dtype:In particular, when the input column is
uint64, the aggregation result should remainuint64unless there is a documented reason for promoting it to a signed integer type.Environment overview (please complete the following information)
Environment details
Please run and paste the output of:
26.08.00
Additional context
I encountered this while aggregating a
uint64column containing view counts.The original Parquet column is
uint64, and it is alsouint64after reading it into cuDF. The dtype changes only when applying the groupby sum:I have also observed the same behavior when performing a second groupby aggregation on an already aggregated
uint64column.As a workaround, I currently cast the result back to
uint64:This is particularly relevant when maintaining a consistent schema across dataframe engines, where the equivalent aggregation preserves
uint64.