thisisnic opened a new issue, #55334:
URL: https://github.com/apache/arrow/issues/55334
### 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:
```r
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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]