emilk opened a new issue, #10534:
URL: https://github.com/apache/arrow-rs/issues/10534

   ### Describe the bug
   
   In 
[`parquet-geospatial/src/bounding.rs`](https://github.com/apache/arrow-rs/blob/main/parquet-geospatial/src/bounding.rs#L116-L117),
 `GeometryBounder::x()` compares the width of the Cartesian bounds against the 
width of the candidate wraparound bounds:
   
   ```rust
   let out_width = (self.x_left.hi() - self.wraparound_hint.lo())
       + (self.wraparound_hint.hi() - self.x_right.hi());
   ```
   
   The interval that is actually returned is 
`WraparoundInterval::new(self.x_right.lo(), self.x_left.hi())`, so the 
right-hand segment runs from `x_right.lo()` to `wraparound_hint.hi()`. The 
second term should therefore use `x_right.lo()`, not `x_right.hi()`.
   
   Because `x_right.lo() <= x_right.hi()`, `out_width` is underestimated, so 
the "are the Cartesian bounds tighter?" check can fail even when they are.
   
   ### To Reproduce
   
   With a wraparound hint of `(-180, 180)` and x values in `[-10, -2]` and 
`[170, 175]`:
   
   * Cartesian bounds are `(-10, 175)`, width **185**.
   * Wraparound bounds are `(170, -2)`, width **188**.
   
   `x()` returns the wraparound bounds even though the Cartesian bounds are 
tighter. Changing `x_right.hi()` to `x_right.lo()` makes it return `(-10, 
175)`, and the existing `parquet-geospatial` test suite still passes.
   
   ### Expected behavior
   
   `x()` should return whichever of the two bounds is narrower — here, the 
Cartesian bounds.
   
   ### Additional context
   
   The bounds remain valid (they still contain all the input), so this is a 
tightness bug rather than a correctness one: the statistics written to Parquet 
are wider than necessary, which weakens row-group pruning.
   
   Found by enabling `clippy::suspicious_operation_groupings` while working on 
#10533.
   
   🤖 Reported by Claude


-- 
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]

Reply via email to