GH-51224: [C++] Keep the correct nulls when winsorizing a sliced array

[1fanwang]

Rationale for this change

Winsorizing a sliced array can put nulls in the wrong positions. Slices containing only nulls or NaNs can also return values from outside the slice.

Closes #51224.

What changes are included in this PR?

Use the bitmap helper to match validity bits to the output values. Preserve the input offset when returning the original buffers.

Are these changes tested?

I ran the native C++ tests and PyArrow on macOS arm64 with Apple clang 21. The new regression covers null-only, NaN-only and mixed null/NaN slices, with chunked inputs as controls.

With PyArrow loading the native library being tested, save this as repro-winsorize.py:

import pyarrow as pa
import pyarrow.compute as pc

parent = pa.array([1.0, 2.0, None, 4.0, None, 6.0, 7.0, 8.0])
result = pc.winsorize(parent.slice(2, 5), lower_limit=0.0, upper_limit=1.0)
print("mixed slice:", result.to_pylist(), flush=True)

parent = pa.array([1.0, 2.0, None, None, None, 3.0])
nulls = pc.winsorize(parent.slice(2, 3), lower_limit=0.0, upper_limit=1.0)
print("all-null slice:", nulls.to_pylist(), flush=True)
assert result.to_pylist() == [None, 4.0, None, 6.0, 7.0]
assert nulls.to_pylist() == [None, None, None]

Raw logs

Before:

$ python repro-winsorize.py
mixed slice: [0.0, 4.0, None, 6.0, None]
all-null slice: [1.0, 2.0, None]
AssertionError

After:

$ python repro-winsorize.py
mixed slice: [None, 4.0, None, 6.0, 7.0]
all-null slice: [None, None, None]
exit_code=0
$ build/release/arrow-compute-vector-test
[  PASSED  ] 1157 tests.
$ build/release/arrow-compute-aggregate-test --gtest_filter='*Quantile*:*TDigest*'
[  PASSED  ] 28 tests.

Are there any user-facing changes?

Sliced inputs retain the correct values and null positions.

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

• GitHub Issue: [C++] winsorize on a sliced array ignores the offset: wrong rows come out null #51224

[github-actions]

⚠️ GitHub issue #51224 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51224 has no components, please add labels for components.

[Copilot]

🟢 Approval recommended

The change correctly addresses the sliced-offset bitmap bug and includes targeted regression tests, with only a minor optional performance optimization noted.

Pull request overview

Fixes winsorize producing an incorrect null pattern when the input is a sliced ArrayData with a non-zero offset, by ensuring the output’s zero-offset validity bitmap matches the slice rather than the parent.

Changes:

• Copy the validity bitmap slice into the zero-offset output in Winsorize::ClipValues (instead of sharing the input bitmap buffer).
• Add regression coverage for sliced floating-point and integer inputs (plus a null-free sliced input case).

File summaries

File	Description
cpp/src/arrow/compute/kernels/vector_statistics.cc	Ensures winsorize output validity bitmap matches sliced input offsets by copying the relevant bits.
cpp/src/arrow/compute/kernels/vector_statistics_test.cc	Adds a regression test verifying correct null placement for sliced inputs across numeric types.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

ClipValues doesn’t explicitly force out->offset = 0, which can break correctness and potentially cause out-of-bounds writes when invoked with a non-zero output offset (e.g., sliced chunks in the chunked path).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The fix directly addresses the reported offset/bitmap bug with a targeted, safe change and includes a focused regression test that fails before and passes after the patch.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The fix is localized, addresses the described root cause (offset-aware validity), and is covered by targeted regression tests.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

[github-actions]

⚠️ GitHub issue #51224 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51224 has no components, please add labels for components.

[github-actions]

⚠️ GitHub issue #51224 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51224 has no components, please add labels for components.

[Copilot]

Copilot review overview

🔵 Needs a closer look

The scalar early-return path can still mishandle validity offsets for sliced all-null/NaN inputs.

Review effort: Lite
Findings: None

[github-actions]

⚠️ GitHub issue #51224 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51224 has no components, please add labels for components.

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved review comments remain.

Review effort: Lite
Findings: None

[github-actions]

⚠️ GitHub issue #51224 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #51224 has no components, please add labels for components.

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved blocking issues were identified.

Review effort: Lite
Findings: None