Three more ways to choose a PCA component count, and retire the fourth

[kgdunn]

A survey of how other packages cross-validate a PCA turned up two schemes worth having and one worth removing. All three changes are on PCA.select_n_components.

Added

cv_scheme="ek", the two-model scheme of Eastment and Krzanowski (1982). An element is predicted by a score from a decomposition that dropped its column and a loading from one that dropped its row, so it enters neither. This is what Simca-P reports as its PCA Q2 and what pcaMethods::Q2 computes by default in R, so it is the scheme to reach for when a number has to line up with either. Rows and columns are each split into cv groups rather than deleted one at a time, costing 2 * n_folds decompositions instead of n + p, and every fold model's singular vectors are sign-aligned to the full-data fit.

One leak is documented rather than hidden. Centring and scaling are fitted once on the whole matrix, as in the classical scheme and in the reference implementations, so a cell reaches the fold models through its own column's centre and spread even though it is absent from both decompositions. That path is of order 1/n. It is why this is an option and not the default.

cv_scheme="sacv" and cv_scheme="gcv", the leverage corrections of Josse and Husson (2012). These get leave-one-cell-out without refitting anything: inflate each residual by the leverage of the cell that produced it, (1 - 1/n - a_i)(1 - b_j), the same device that turns a regression residual into its leave-one-out counterpart via e_i / (1 - h_ii). "gcv" replaces the two leverages with one averaged constant and is blunter. Both are the defaults in FactoMineR and missMDA.

The point is cost. On a 100 by 12 block, "sacv" costs one decomposition against 560 for the element-wise scheme, picks the same component count, and stays within five points of its curve through the optimum:

Components	ekf	sacv
2	0.786	0.791
3	0.883	0.891
4	0.821	0.845
8	0.549	−0.044

The last row is the trap, and it is pinned by a test. Both leverage schemes are first-order approximations that degrade as the components approach the variables, because a column's leverage is the share of its variance inside the retained subspace and reaches one when the components reach the variables. The divisor goes to zero with it. The docstring and the user guide say to read them well below that ceiling, which is why FactoMineR defaults to five.

All three factorise the matrix directly, so they raise a clear ValueError on a block with missing cells and point at "ekf", which imputes an unmeasured cell alongside the held-out ones and never scores it. The refusal names how many cells are missing and whether one column holds them, because that decides the repair: on the FMC dryer's quality block 18 of the 19 sit in one attribute, so dropping that column keeps all 46 batches where dropping the incomplete rows would cost 19 of them. A block whose gaps are scattered has no such repair, and the message says which case it is. The three schemes also ignore scale_inside_folds, n_repeats, n_iter and tol, and they report no per-fold spread, since nothing is held out in folds that could disagree. A fabricated zero there would let the 1-SE rule read a false certainty, so the field is NaN instead.

Deprecated

cv_scheme="row_wise" now emits a DeprecationWarning and will be removed in 2.0, following docs/development/deprecation_policy.rst. It measures how well a held-out row reproduces itself: the row supplies the scores that rebuild it, so PRESS falls monotonically and reaches exactly zero once the components equal the variables. That is a compression error, not a prediction error, and it cannot select a component count. mdatools removed the equivalent from its own PCA and said in its release notes that it "was a bad idea from the beginning". The existing SpecificationWarning still fires alongside.

The FMC quality block shows it plainly. On its complete 46 by 6 sub-block the row-wise scheme climbs -0.11, 0.93, 0.95, 0.97, 0.999, 1.000 and recommends six components, the number of attributes; "ekf" on the same block recommends one.

Fixed

The leverage criterion could report a perfect score on an empty total. Found by running every scheme over the whole component range on the FMC quality block, which is narrow enough (six to eight attributes) to reach the ceiling. Once the components reach the variables every column leverage is one, so the guard in "sacv" drops every cell as undefined. np.nansum of an all-NaN array is 0.0, not NaN, so PRESS came back as zero and Q2 as exactly 1.000, which then won the selection outright: six components on a 46 by 6 block and eight on a 27 by 8 one, the worst answers available. "gcv" already guarded its own version of this; "sacv" did not. It now reports NaN there, and recommends 1 and 2 on those two blocks.

Where only some cells are dropped, the criterion and the reference it is divided by now cover the same cells. The previous code compared an error over part of the block against a null over all of it, which flatters the model in proportion to how many cells were dropped. Nothing is dropped early on real data, so no published number moves; a high-leverage outlying row is what reaches this path.

The no-optimum warning named the scheme it was warning about. Its remedy listed both element-wise schemes whatever was running, so a caller already using "ekf" was told to use "ekf". It now names only the alternatives, and says how many component counts it could actually evaluate rather than how many were asked for. The guard that built that remedy conditionally has gone with it: the list is the two schemes less whichever is running, so one always survives.

Why the default did not change

The likelihood route that scikit-learn takes is elegant and immune to the circularity, but it assumes isotropic noise. On a rank-3 block with the noise ramped from 0.3 to 3.0 across the variables, which is ordinary for a plant with sensors of differing quality, the cross-validated log-likelihood and Minka's estimate both take ten or eleven components across five seeds while the element-wise scheme takes three every time. "ekf" stays the default.

Two datasets since bore that out from the other side. On LDPE, "ekf" and "ek" both turn over at two components as Simca-P does (correlation with the recorded Simca-P curve +0.86 and +0.65 over the first eight counts), while "sacv" and "gcv" do not turn over at all there, because the fit reaches 99.98% and the residual they inflate has nothing left in it. On the FMC quality block, whose 19 missing cells are the ordinary case for plant data, "ekf" is the only one of the four that will run at all.

Verification

• uv run pytest: 3235 passed, 3 skipped, coverage 94.20% against the 92% gate. (An earlier revision of this description said 3234; that was the count before the last test landed.)
• Fourteen new tests, including the defining property of the Eastment-Krzanowski scheme checked rather than assumed: perturb a cell by 1000 and the scores from the decomposition that dropped its column move by less than 1e-12; and the two guards above, each pinned on a shape where it fires.
• ruff check ., ruff format --check . and mypy src/process_improve all clean on the current head.
• The strict Sphinx docs build (-W) succeeds.
• CHANGELOG.md, pyproject.toml and CITATION.cff all at 1.84.0, dated 2026-09-10, a MINOR bump for new features. The fixes above are to code this PR itself adds, so they are folded into that entry rather than bumping again.
• No lock file staged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LXthGpHLQFfGubBiKFtGAE

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!