PERF Vectorize sparse path of PolynomialCountSketch.transform - #34919

Reference Issues/PRs

See #34920 (not using a closing keyword since the issue is still pending
triage).

What does this implement/fix? Explain your changes.

PolynomialCountSketch.transform's sparse branch loops over every feature
and every degree, slicing one sparse column at a time and calling
.toarray() on it:

for j in range(X_gamma.shape[1]):
    for d in range(self.degree):
        iHashIndex = self.indexHash_[d, j]
        iHashBit = self.bitHash_[d, j]
        count_sketches[:, d, iHashIndex] += (
            (iHashBit * X_gamma[:, [j]]).toarray().ravel()
        )

This densifies a full (n_samples,) array on every iteration regardless of
column sparsity, so cost scales with n_features * degree instead of the
number of nonzeros. On a 1%-density matrix with a few thousand features, the
sparse path ends up an order of magnitude slower than just densifying the
whole input and using the dense branch.

This PR replaces the double loop with one sparse matrix multiplication per
degree: scale columns by bitHash_[d, :] via .multiply(...), then
scatter-sum into buckets with a sparse 0/1 projection matrix built from
indexHash_[d, :]. Output is unchanged.

Local benchmark (2000 samples, 300 components, degree=2, 1% density):

Important: this PR always improves on the code it replaces. The table
below (1000 samples, 200 components, degree=2, 2000 features, varying
density) makes both comparisons explicit — old-vs-new (the one that matters
for approval) and new-vs-dense (context on the sparse/dense crossover):

The old sparse path was uniformly ~0.15-0.16s regardless of density,
because its cost was driven by loop count (n_features * degree) rather
than the data itself. The new path's cost scales with the number of
nonzeros, so it is dramatically faster than the old path at every density
tested — 5x to 78x depending on density — even though at high density (>~20%)
it is still somewhat slower than simply densifying the input and using the
unrelated dense branch, which is expected of any sparse algorithm and not a
regression: a 50-80%-dense matrix stored as a sparse type is already an
unusual choice on the caller's part, and the fix never makes that case worse
than main, only better.

Note on dense input: the else branch handling dense arrays is untouched by
this PR (byte-for-byte identical diff), and measured dense transform timing
is unchanged before/after within run-to-run noise.

Since this is a performance fix rather than a correctness bug, the existing
test_polynomial_count_sketch_dense_sparse test passes on both the old and
new implementation (both are correct, just different speeds), so it alone
doesn't prove the new code is right. I added
test_polynomial_count_sketch_sparse_edge_cases, covering all-zero sparse
columns and a single-feature/single-sample input, shapes not exercised by the
existing random test data. I confirmed this new test is not vacuous: I
temporarily broke the new vectorized code (dropped the sign-hash multiply)
and the new test failed with a clear mismatch, then restored the fix.

Verification:

• pytest sklearn/tests/test_kernel_approximation.py -> 80 passed
• check_estimator(PolynomialCountSketch()) passes
• ruff check / ruff format --check clean

Introduce yourself

I use scikit-learn for general ML work. While checking the open-issue
backlog for something to contribute, I found it heavily claimed (most open
Bug/Documentation/good first issue/help wanted issues already had a
competing PR or an active claim comment), so I looked for an improvement by
reading source directly instead, and found this inefficiency in
kernel_approximation.py.

AI usage disclosure

I used AI assistance for:

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Research and understanding

Any other comments?

Already added the efficiency changelog entry under
doc/whats_new/upcoming_changes/sklearn.kernel_approximation/34919.efficiency.rst.

Opened #34920 to report the bug ahead of this PR per the contributing
guidelines. It's pending triage, so this PR references it without a closing
keyword for now and I'll switch to Fixes #34920 once the label is cleared.