GH-49888: [C++][Compute] Fix count for run-end encoded arrays with nulls

[fenfeng9]

Rationale for this change

The count kernel used GetNullCount(), which reports the physical null count. For run-end encoded arrays, this ignored nulls in the encoded values child.

What changes are included in this PR?

Use ComputeLogicalNullCount() in the count kernel so run-end encoded arrays are counted correctly. Add C++ and Python tests for this case.

Are these changes tested?

Yes.

Are there any user-facing changes?

No.

• GitHub Issue: [C++][Compute] count kernel miscounts when run-end encoded array contains null #49888

[fenfeng9]

The added tests use a simplified version of the reproducer from the issue.

Reproduce

importpyarrowaspaimportpyarrow.computeaspcarray=pa.array([1, None])
encoded=pc.run_end_encode(array)
print(f"plain only_null: ", pc.count(array, mode="only_null"))
print(f"run_end_encode only_null: ", pc.count(encoded, mode="only_null"))

Result

plain only_null: 1
run_end_encode only_null: 0

[tadeja]

Thank you for the fix, @fenfeng9 ! 🌞 A few additional test suggestions from my end as inline comments.
The MinGW64 CI failures look unrelated. There were some overlapping failures on main.

[fenfeng9]

Thanks for the suggestion. I updated the C++ and Python tests.

[fenfeng9]

The original behavior is:

Reproduce

importpyarrowaspaimportpyarrow.computeaspcarray=pa.array([1, 1, None, None, None, 2, 2, 2, None, 3])
encoded=pc.run_end_encode(array)
# Logical slice: [None, None, 2, 2, 2, None].slice_plain=array.slice(3, 6)
slice_encoded=encoded.slice(3, 6)
print("pyarrow:", pa.__version__)
print()
print(f"{'case':<12}{'only_valid':>10}{'only_null':>10}{'all':>6}")
forname, valuein [
("plain", array),
("ree", encoded),
("slice plain", slice_plain),
("slice ree", slice_encoded),
]:
print(
f"{name:<12} "f"{pc.count(value, mode='only_valid').as_py():>10} "f"{pc.count(value, mode='only_null').as_py():>10} "f"{pc.count(value, mode='all').as_py():>6}"
)

Result

pyarrow: 24.0.0
case only_valid only_null all
plain 6 4 10
ree 10 0 10
slice plain 3 3 6
slice ree 6 0 6

[fenfeng9]

The test failures look unrelated.

[pitrou]

Thank you @fenfeng9 !

[pitrou]

And thanks @tadeja for the useful reviewing!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 0 benchmarking runs that have been run so far on merge-commit 1b3f313.

None of the specified runs were found on the Conbench server.

The full Conbench report has more details.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 2 benchmarking runs that have been run so far on merge-commit 1b3f313.

There was 1 benchmark result with an error:

• Commit Run on amd64-m5-4xlarge-linux at 2026-05-15 02:41:57Z
  • csv-read (Python) with compression=uncompressed, dataset=nyctaxi_2010-01, output_format=arrow_table, streaming=streaming

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 8 possible false positives for unstable benchmarks that are known to sometimes produce them.