BiorthBasis parameter 'subsamp' and 'samplesz' are duplicates!

[The9Cat]

Summary

As identified by @jngaravitoc, we use both subsamp and samplesz, in pyEXP and EXP respectively, to indicate the number of bootstrap subsamples for covariance estimation.

Changes

These should be the same. This PR replaces subsamp by samplesz while still allowing subsamp and emits a deprecation warning if subsamp is used.

pyEXP docstrings updated for consistency with this change.

[Copilot]

Pull request overview

Aligns the configuration key used to set the number of bootstrap subsamples for coefficient covariance: pyEXP/expui BiorthBasis-derived classes (Spherical, Cylindrical, FlatDisk, Cube) now accept samplesz in addition to the legacy subsamp key, matching the convention already used in the EXP runtime (src/Cube.cc, src/Cylinder.cc, src/AxisymmetricBasis.cc). Use of subsamp still works but emits a deprecation warning, and the top-level pyEXP covariance documentation is updated to refer to samplesz.

Changes:

• Parse samplesz (after subsamp, so it takes precedence) in Spherical, Cylindrical, FlatDisk, and Cube initializers.
• Emit a deprecation warning when the legacy subsamp key is supplied; also relabel the existing eof_file warning prefix from Cylinder to Cylindrical.
• Update the top-level covariance docstring in pyEXP/BasisWrappers.cc to describe samplesz (and rename subsamp to samplesz in the returned-array dimension description).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
expui/BiorthBasis.cc	Adds samplesz parsing alongside subsamp plus deprecation warnings in four BiorthBasis classes; fixes one warning prefix.
pyEXP/BasisWrappers.cc	Renames subsamp → samplesz in the general covariance documentation block.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[michael-petersen]

Thanks, and I like the deprecation warning. I think we had loosely been trying to enforce a policy where we specify that the next minor release will deprecate the feature, so we could be explicit here (e.g. 7.11) , or just leave this vague.

[The9Cat]

Ah, you are right. I'll add 7.11 to the warning. To be helpful, we could convert these same deprecation warnings to exceptions at 7.11.