DiadkoShmek opened a new issue, #55393:
URL: https://github.com/apache/arrow/issues/55393
### Describe the bug
PyArrow 26.0.1 on Linux x86-64:
```python
import pyarrow as pa
import pyarrow.compute as pc
pc.round(pa.array([250000000000.0]), ndigits=-11).to_pylist()
# [299999993856.0]
pc.round_binary(pa.array([250000000000.0]), pa.array([-11])).to_pylist()
# [299999993856.0]
```
The default half-even result should be `200000000000.0`. The input, halfway
point and expected result are exactly representable; the returned value is not
a multiple of `100000000000`.
Current main `690ed5665832e10358618614e506c590f2a61bf9` retains
float-suffixed constants in `RoundUtil::Pow10`
(`cpp/src/arrow/compute/kernels/scalar_round.cc:93-94`), so double scale
factors first lose float32 precision. Separately compiled base/candidate copies
of that exact production translation unit, registered in private registries
against the same PyArrow26 support libraries, reproduce the defect and the
effect of correcting the constants. This was not a full current-main build.
A simple constant correction is not sufficient for submission: it exposes a
false tie for `x = float.fromhex('-0x1.6bcc41e8fffffp+45')`, `ndigits=-14`,
`half_down`. This input is exactly `-49999999999999.9921875`, above the exact
halfway point by `1/128`. The base returns `-0.0`, but corrected constants
return `-100000000000000.0`; subtracting `floor(round_val)` rounds the
fractional part to exactly `0.5`.
There is also a compatibility question before a broader rounding repair:
existing tests expect `-3.045`, two digits, `half_towards_infinity` to produce
`-3.05`, whereas exact rounding of that binary64 input would produce `-3.04`.
Should a repair preserve the existing scale-first convention for these cases? I
have held off a PR while the scale precision and false-tie behavior are
unresolved together.
### Component(s)
C++, Python
AI assistance: investigation, native checks and a separate adversarial
review used Codex; no personal human code review is claimed.
--
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]
