Boulea7 opened a new issue, #11282:
URL: https://github.com/apache/arrow-rs/issues/11282
### Describe the bug
Summing a sliced run-end encoded array can use incorrect run lengths. On
main (`a297bdb88ca91b4c7b3b2fd17c4dde191a250e7f`), the slice below contains
`[10, 100, 100, 100]`, but `sum_array` returns `Some(130)` instead of
`Some(310)`.
### To Reproduce
```rust
use arrow_arith::aggregate::sum_array;
use arrow_array::types::{Int16Type, Int32Type};
use arrow_array::{Int16Array, Int32Array, RunArray};
let run_ends = Int16Array::from(vec![4, 8]);
let values = Int32Array::from(vec![10, 100]);
let array = RunArray::<Int16Type>::try_new(&run_ends, &values).unwrap();
let sliced = array.slice(3, 4);
let typed = sliced.downcast::<Int32Array>().unwrap();
assert_eq!(sum_array::<Int32Type, _>(typed), Some(310));
```
The assertion fails with `left: Some(130), right: Some(310)`.
### Expected behavior
The sum should be `Some(310)`, matching the values in the logical slice.
### Additional context
`sliced_values()` already returns run ends relative to the slice. The sum
fold then clamps them using the original offset, which changes the run lengths.
AI disclosure: This report and reproduction were generated with AI
assistance.
--
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]
