Skip to content

bug: marrow GroupBy sum/min/max loses precision for large int64 values (> 2^53) #601

Description

@JRedrupp

Summary

The marrow hash-aggregate GroupBy kernel accumulates sum, min, and max as float64 internally, even for int64 value columns. The result is then cast back to Int64. For values exceeding 2^53 (~9.0e15), this round-trip through float64 loses precision that the native int64 path preserves.

Background

Introduced by the marrow GroupBy integration (#583). The marrow kernel's AggregateFunction stores running values as float64 (see vendor/marrow/marrow/kernels/groupby.mojo, AggregateFunction.__init__). The bison _marrow_agg helper casts the float64 result back to Int64 via Int64(Float64(scalar)).

The native (non-marrow) fallback path uses Column.sum_int64(), Column.min_int64(), Column.max_int64() which accumulate natively in Int64 and preserve full precision.

Impact

Low in practice — most real-world groupby aggregations involve values well within float64's exact integer range. But it is a subtle correctness difference between the marrow and native paths.

Possible fixes

  1. Document the limitation — note in code comments that the marrow path has reduced precision for very large integers
  2. Add an int64 accumulator path to marrow's AggregateFunction — upstream change in marrow to use int64 state when the input dtype is int64 and the aggregation is sum/min/max
  3. Skip marrow path for int64 columns — only use marrow for float64 value columns, keep native path for int64 (loses half the perf benefit)

Option 2 is the best long-term fix but requires changes in the marrow library.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    tech-debtTechnical debt items

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions