Skip to content

docs: correct core transforms/profiling docstrings to match code (v0.22.1) - #102

Open
kgdunn wants to merge 1 commit into
mainfrom
claude/ecstatic-johnson-h4o709
Open

docs: correct core transforms/profiling docstrings to match code (v0.22.1)#102
kgdunn wants to merge 1 commit into
mainfrom
claude/ecstatic-johnson-h4o709

Conversation

@kgdunn

@kgdunn kgdunn commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Summary

A docstring audit across the computational and user-facing functions in src/scorepilot/ found two clear drifts between docstrings and code. Both are in core/, the numerical engine, so users reading the API docs would be actively misled.

1. apply_transformsrc/scorepilot/core/transforms.py

The Notes section documented the POWER transform as:

power: sign(x) * abs(x) ** c1 (default c1 = 0.5, i.e. signed root)

Two problems:

  • The signature default is c1: float = 0.0, not 0.5.
  • _transform_values uses exponent = c1 if c1 != 0.0 else 0.5, so passing c1=0.0 (the default) produces the signed square root, not sign(x) * abs(x) ** 0 = sign(x) as the stated formula would imply.

Rewritten to match the actual guard, so both the formula and the default line up with what the code does.

2. suggest_transformsrc/scorepilot/core/profiling.py

The docstring said:

a milder skew suggests a signed power (root)

But both LOG and POWER gate on the same strongly_skewed = summary.skewness > 1.0 threshold. POWER is returned when a variable is strongly skewed but fails LOG's positivity or wide-range preconditions — not when the skew is milder. Values with skewness <= 1.0 return NONE, never POWER.

Rewritten to describe the actual branching.

Files touched

  • src/scorepilot/core/transforms.py — docstring only (line 51).
  • src/scorepilot/core/profiling.py — docstring only (lines 143–147).
  • pyproject.toml — version bump to 0.22.1 (PATCH).
  • uv.lock — refreshed to match the new version (per CLAUDE.md's "refresh the lockfile in the same PR" rule).

No behavioural change; docs-only correctness fix.

Test plan

  • Docstrings now describe the actual branching / defaults for both functions.
  • pyproject.toml version bumped; uv.lock refreshed so uv sync --frozen still resolves.
  • CI (uv run pytest, ruff, pyright) is green on the PR.

The audit did not flag any other real docstring/code inconsistencies in core/, api/, db/, dataset_store.py, samples.py, config.py, schemas.py, or main.py (cross-validation defaults, quality_report tolerance semantics, fit_model / observation_contributions / fit_pca / cross_validate return shapes, and apply_spec / _center_scale behaviour all matched their docstrings).


Generated by Claude Code

Two computational-function docstring drifts caught by an audit pass:

1. apply_transform (core/transforms.py): the Notes section documented the
   POWER transform as sign(x) * abs(x) ** c1 with default c1 = 0.5. But
   the signature default is c1 = 0.0, and _transform_values uses
   'exponent = c1 if c1 != 0.0 else 0.5'. Passing c1=0.0 therefore
   produces the signed square root, not sign(x) * abs(x) ** 0 = sign(x)
   as the stated formula would imply. Rewrite the formula to match the
   guard.

2. suggest_transform (core/profiling.py): the docstring said 'a milder
   skew suggests a signed power (root)', but both LOG and POWER gate on
   the same strongly_skewed = summary.skewness > 1.0 threshold. POWER is
   returned when the variable is strongly skewed but fails LOG's
   positivity or wide-range preconditions, not when the skew is milder.
   Values with skewness <= 1.0 return NONE, never POWER.

Bump version to 0.22.1 (PATCH: docs-only, no behavioural change).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtFYvCesNLLVKrxoUk2M8r
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants