Skip to content

[R] %% returns wrong results for decimals and errors for large int64; use the modulo kernel #55334

Open

Description

@thisisnic

Describe the bug, including details regarding any error messages, version, and platform.

The R package emulates %% as x - y * (x %/% y), in Ops.ArrowDatum (arrow-datum.R) and Expression$op() (expression.R). The %/% step casts both operands to double, so inputs beyond double precision give wrong answers or fail:

library(arrow)
library(bit64)

# int64 above 2^53: errors
Array$create(as.integer64("9007199254740993")) %% 7L
#> Error: Invalid: Integer value 9007199254740993 not in range: -9007199254740992 to 9007199254740992

# decimal with 20 significant digits: silently wrong
d <- Scalar$create("12345678901234567890.12", string())$cast(decimal128(25, 2))
as.vector(d %% 7L)
#> [1] 722.12
# correct answer is 1.12

Arrow C++ 26.0.0 added modulo and modulo_checked (#46901), floored like R's %% (result takes the sign of the divisor), with native int64 and decimal support. call_function("modulo", ...) gives 5 and 1.12 for the two cases above.

Both code paths should call modulo directly. .operator_map in dplyr-funcs-simple.R has a placeholder entry mapping %% to divide_checked with a comment saying it isn't used; that can go too.

One behaviour to preserve: R returns NA for integer x %% 0L and the current emulation matches that, whereas modulo errors with "divide by zero". The new binding needs an if_else on a zero divisor like the one %/% already has.

Drafted with AI assistance.

Component(s)

R

Activity

  1. huong8373tt-beep commented on Oct 31, 2026

    @huong8373tt-beep

    I would like to work on this issue. I plan to replace the two R-level %% emulations with the existing Arrow modulo kernel, preserve the integer-zero-divisor NA behavior, remove the unused operator-map placeholder, and add focused regression coverage for int64 and decimal inputs. I will wait for assignment before changing code.

    Slai Agent Runtime performed the investigation, implementation, and test execution. The account owner authorized this contribution and is responsible for its content.

  2. huong8373tt-beep commented on Oct 31, 2026

    @huong8373tt-beep

    I found the already-open fix in #55338 after posting my interest, so I will not duplicate work on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions