Skip to content

[MINOR][SQL] Remove redundant second modulo in integral MathUtils.pmod - #58906

Open
david-mollitor-db wants to merge 1 commit into
apache:masterfrom
david-mollitor-db:pmod-drop-redundant-modulo
Open

david-mollitor-db wants to merge 1 commit into
apache:masterfrom
david-mollitor-db:pmod-drop-redundant-modulo

Conversation

@david-mollitor-db

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

The integral MathUtils.pmod overloads (Int, Long, Byte, Short) compute the positive
remainder as:

val r = a % n
if (r < 0) (r + n) % n else r

For integer types the trailing % n is redundant. a % n yields a value whose magnitude is
strictly less than |n|, so when r < 0 it lies in (-|n|, 0) and r + n is already in
[0, n). This PR removes the second modulo, leaving:

val r = a % n
if (r < 0) r + n else r

The Float/Double overloads are left unchanged on purpose: floating-point rounding can round
r + n up to exactly n, and the extra % n folds that back to 0, so there it is a real
correctness guard rather than a no-op.

Why are the changes needed?

MathUtils.pmod backs the pmod SQL function and the per-row partition-id expression of
HashPartitioning (Pmod(Murmur3Hash(...), numPartitions)), so it runs once per row on the map
side of every hash-partitioned shuffle. The trailing % n is dead computation. Removing it is a
small readability and efficiency cleanup: besides skipping an operation, it lets the JIT compile
the function to branchless, single-division code (the second modulo otherwise sits in a branch
that cannot be turned into a conditional move).

Does this PR introduce any user-facing change?

No. The result is identical for all inputs; only redundant computation is removed.

How was this patch tested?

Existing pmod coverage (e.g. ArithmeticExpressionSuite) continues to apply. The old and new
integral forms were additionally cross-checked for exact equality over 18M random inputs plus
boundary values (including Int.MinValue / Long.MinValue, 0, +/-1, +/-n) across
power-of-two and non-power-of-two divisors, with zero mismatches.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Isaac

This pull request and its description were written by Isaac.

The integral `MathUtils.pmod` overloads (Int, Long, Byte, Short) compute
`if (r < 0) (r + n) % n else r`, where `r = a % n`. In exact integer
arithmetic a negative `r` lies in `(-|n|, 0)`, so `r + n` is already in
`[0, n)` and the trailing `% n` is a no-op. Drop it, leaving
`if (r < 0) r + n else r`.

The change is behavior-preserving: the two forms were verified equivalent
over 18M random and boundary inputs (including Int.MinValue) across
power-of-two and non-power-of-two divisors.

The float/double overloads intentionally keep the second modulo:
floating-point rounding can make `r + n` round up to exactly `n`, which
`% n` folds back to `0`.

`pmod` backs the `pmod` SQL function and `HashPartitioning`'s per-row
partition-id expression; dropping the extra modulo also lets the JIT emit
branchless, single-division code for the function.

Co-authored-by: Isaac <no-reply@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant