I’ve packaged a small, model-agnostic tool for probing the joint structure of a population via the correlation dimension (Grassberger–Procaccia D₂), and I’d value feedback from people working on population inference.
The motivation: marginal-histogram comparisons are blind to joint geometry — two catalogs can match on every 1D marginal yet differ in correlation structure. D₂ catches this.
The caveat I want to flag (and the reason I’m posting rather than just linking): applying D₂ to catalog point estimates systematically overstates structure. On the GWTC BBH catalog the point-estimate deficit (D₂≈2.165) largely vanishes under posterior propagation (D₂≈2.44, ~0.7σ below null — not significant). The package enforces three checks (marginal-shuffle null, subsample variance, posterior propagation) before any deficit is trusted.
Question for the community: for those who’ve applied geometric/fractal descriptors to GW catalogs — does this point-estimate inflation match what you’ve seen, and are there standard mitigations beyond full posterior propagation I should be aware of?
Package + zenodo.20819117 · Methods write-up zenodo.20783365
This is very useful, especially the warning about point estimates overstating structure. I’m working on an early simulation-stage AI tuning/validation system where multiple telemetry channels are compared together rather than trusted individually. One of those planned channels is FCAM, a field-sensing front end, alongside phase, thermal, noise, and safety-state telemetry.
What interests me here is not using D₂ as a claim-maker, but as a safeguard: can methods like marginal-shuffle nulls, subsample variance, and posterior/uncertainty propagation help determine whether an AI tuner is detecting real joint structure or simply amplifying noise, drift, sampling bias, or point-estimate artifacts?
I’m still at the validation/prototype stage and would be interested in feedback or possible student collaboration on adapting these geometric checks to multi-signal simulation data. The goal would be disciplined testing, not overclaiming.
Thanks for reading it so carefully — you’ve picked up exactly the point I most wanted to land: D₂ is most useful as a safeguard, not a claim-maker. That matches my own experience: my GWTC black-hole result looked like clean low-dimensional structure on point estimates (D₂≈2.17, below the shuffle null), but it largely dissolved once I propagated the real per-event posteriors (D₂ rose to ~2.44, ~0.7σ below null, not significant). So the cautionary finding was the finding.
On your question — yes, the three checks can help separate real joint structure from amplified noise/drift/sampling bias, but each targets a different failure mode:
- Marginal-shuffle null tests whether the joint geometry carries information beyond the per-channel marginals. Permute each channel independently, recompute. If real data isn’t separated from shuffled, what you’re seeing lives in the marginals, not the joint structure.
- Subsample variance (without replacement, or jackknife — avoid naive bootstrap with replacement, duplicate points have zero pairwise distance and bias the metric) tests whether the result hangs on a few influential samples.
- Posterior/uncertainty propagation is the one most people skip and the one that matters most: if each reading is really a distribution, collapsing it to a point systematically overstates structure.
Two honest caveats for your setting: my work is on a catalog of discrete events, not multi-channel time series, so you’ll need to think carefully about what “distance” means across heterogeneous channels (FCAM vs thermal vs safety-state aren’t naturally commensurable — standardization choices will affect the answer); and these diagnose whether structure is real, not what it is.
The code is open (corrdim on Zenodo, MIT-licensed, doi:10.5281/zenodo.20819117) with all three tests built in, so you’re welcome to apply it to your data directly.
On the collaboration question: I’m based at a research centre (hydro- and aerodynamics) and that’s my main commitment, so my available time is limited — but I’m genuinely happy to give methodological feedback as you prototype, and could potentially be involved in a more defined way depending on scope. To gauge that, it’d help to understand the context a bit: is this academic research, an industrial/product R&D effort, and who’s behind it? That just helps me figure out how I could realistically contribute. Either way, the “disciplined testing, not overclaiming” goal is the right one, and I’m glad to help pressure-test it.