Sharpe Ratio Non-IID Corrections

Generalized Sharpe ratio inference framework for non-Normal, serially correlated returns. Reference implementation of López de Prado, Lipton & Zoonekynd (2026).

Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

Quick Start

# Run all 18 validation tests (paper Exhibit 1 + numerical examples)
uv run --python 3.13 --with numpy --with scipy --with numba \
  python plugins/quant-research/skills/sharpe-ratio-non-iid-corrections/references/sharpe_numba.py

Paper Metadata

References

Preflight: Experimentation Context Assessment (CRITICAL)

Before computing DSR or SFDR, Claude Code MUST assess the experimentation context to determine the correct parameters. These inputs require subjective judgment that cannot be derived from code alone.

Decision: DSR vs SFDR

Default for this project: Use SFDR. Our strategies are survivors of hundreds of regime explorations across WFO configurations, feature sets, model architectures, and metric cutoffs. The full experimentation history is unrecoverable.

Parameters Requiring Judgment

Before calling

sfdr_threshold()

Preflight Checklist

When this skill is invoked, Claude Code should:

1. Identify the evaluation context: Is this a single new strategy, a WFO fold comparison, or a survivor from extensive search?
2. Determine DSR vs SFDR: If return series for all candidates exist → DSR with K_eff. Otherwise → SFDR.
3. Elicit P[H₁]: Search for experimentation history (git log, experiment catalogues, the

   signal-archaeology

   skill). Count approximate ideas tried vs ideas that worked. If unknowable, use 0.05.
4. Estimate SR₁: From validated production strategies or asset-class benchmarks.
5. Set q: Based on the decision's consequence (research paper vs capital deployment).
6. Compute objective parameters: γ₃, γ₄, ρ, T directly from the return series.
7. Report the assessment: State all parameter choices and reasoning before computing, so the user can override.

Example Preflight Output

SFDR Preflight Assessment:
  Context:    Survivor of ~300 WFO configs × 5 feature sets × 3 architectures
  Method:     SFDR (experimentation history unrecoverable)
  P[H₁]:     0.05 (conservative — ~15 genuine signals from ~300 ideas)
  SR₁:       0.4 (typical monthly Sharpe for validated crypto range bar strategies)
  q:         0.05 (research-grade threshold)
  γ₃:        -2.448 (computed from return series)
  γ₄:        10.164 (Pearson kurtosis, computed from return series)
  ρ:         0.20 (lag-1 autocorrelation, computed from return series)
  T:         24 months
  → SFDR threshold: SR_c = 0.760
  → Observed SR: 0.456
  → VERDICT: FAIL (observed SR below SFDR threshold)

The user may override any parameter. If they disagree with P[H₁] or SR₁, recompute with their values.

Key Formulas

All equations use the paper's non-IID variance (Eq 2-3) with Pearson kurtosis convention (γ₄=3 for Gaussian).

sr_variance()

psr()

min_trl()

critical_sr()

power()

power()

1 - power

pfdr()

ofdr()

expected_max_sr()

dsr()

sfdr_threshold()

Where a = (1+ρ)/(1−ρ), b = (1+ρ+ρ²)/(1−ρ²), c = (1+ρ²)/(1−ρ²) are AR(1) variance coefficients (

ar1_variance_coeffs()

Numerical Example (Paper Exhibit 1)

Hedge fund: T=24 months, γ₃=−2.448, γ₄=10.164 (Pearson), SR=0.036/0.079≈0.456, ρ=0.2.

Implementation Architecture

6-tier dependency hierarchy (Numba JIT, Rust-ready):

Tier 0: norm_cdf, norm_ppf, erfinv, Brent's method
Tier 1: sr_variance (Eqs 3/58)
Tier 2: psr (Eq 9), min_trl (Eq 11), critical_sr (Eq 13)
Tier 3: power (Eq 15), moments_mk (Eqs 62-65), expected_max_sr (Eq 28), var_max_sr
Tier 4: pfdr (Eq 18-21), ofdr (Eqs 22-24), fwer (Eq 25)
Tier 5: dsr (Eqs 29-31), sfdr_threshold (Eqs 32-33)  ← APEX

Related Skills

Post-Execution Reflection

After this skill completes, check before closing:

1. Did the command succeed? — If not, fix the instruction or error table that caused the failure.
2. Did parameters or output change? — If the underlying tool's interface drifted, update Usage examples and Parameters table to match.
3. Was a workaround needed? — If you had to improvise (different flags, extra steps), update this SKILL.md so the next invocation doesn't need the same workaround.

Only update if the issue is real and reproducible — not speculative.