Paper: Trimming the Hairball

[rtbs-dev]

Paper submission accompanying poster

[jrbarhydt]

hello! i'm a reviewer for this paper (J.R. Barhydt)

[github-actions]

Curvenote Preview

Directory	Preview	Checks	Updated (UTC)
papers/rachael_sexton	🔍 Inspect	✅ 69 checks passed (2 optional)	Oct 9, 2026, 5:27 AM

[rtbs-dev]

@jrbarhydt I see the DOI linter is failing a check, though I'm fairly sure that paper only has a HAL ID. See here.

I've updated the other DoIs and added CRediT roles.

[rtbs-dev]

@scipy-conference/2026-proceedings Having a little trouble getting the checks to pass! Let me know how I can get that fixed up.

[jrbarhydt]

My background is not as heavy in software dev-ops stuff. Mostly just code from scientists, etc.
(You could probably open an Italian restaurant with all our spaghetti code :P)

I'll take a look later today and see if I can find anything.

[rowanc1]

Some advice on failing checks, you can mark the errors as resolved in the myst.yml.

[rtbs-dev]

@rowanc1 I took care of the doi issues but the checks are still failing, looks like a Node 20 issue? Or maybe a CI permissions setting?

Node 20 is being deprecated. This workflow is running with Node 24 by default. 
If you need to temporarily use Node 20, you can set the 
ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true 
environment variable. For more information see: 
https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

Run actions/checkout@v4
Error: Refusing to check out fork pull request code from a 'pull_request_target' workflow.
This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope, and runner access. 
Fetching and executing a fork's code in that trusted context commonly leads to "pwn request" vulnerabilities. 
To opt in, review the risks at 
https://gh.io/securely-using-pull_request_target 
and set 'allow-unsafe-pr-checkout: true' on the actions/checkout step.

[rowanc1]

It looks like a security change that GitHub did yesterday. @fwkoch can you look into this? The actions are failing for all of scipy at the moment.

[rowanc1]

This has been fixed up, and looks to all be passing now!!

[freemansw1]

My background is not as heavy in software dev-ops stuff. Mostly just code from scientists, etc. (You could probably open an Italian restaurant with all our spaghetti code :P)

I'll take a look later today and see if I can find anything.

Please go ahead and review the content; we don't expect you to debug the formatting/CI issues.

[jrbarhydt]

@rtbs-dev

Thanks for this submission; it's a really interesting problem space. I have a couple
analysis projects that could use this treatment. The three-library ecosystem (affinis,
MENDR, Contingency) is a clean way to break up the algorithm, benchmark, and metrology
concerns. I'll put my high-level first-pass notes below and follow up with inline
comments in the code.

Written quality

Overall clear and well-organized, with good instincts for explaining jargon to
a general audience in most places (e.g. "hairball," the Laplace/Jeffrey's-prior
smoothing walkthrough). A handful of sentences have grammatical slips that read
like leftover edits (e.g. around lines 84, 185, 439).
A few other terms ("doubly stochastic," "Matrix Forest Theorem," and "bathtub
prior") are used without explanation and could use the same kind of plain-
language treatment "hairball" gets earlier on. I'll leave these as inline comments
rather than list them all here.

Technical Content / Verifiability

I ran the full install and all three notebooks locally. One environment note
worth surfacing early: affinis currently requires Python 3.11 or 3.12
specifically (doesn't resolve on 3.13+), and that constraint isn't mentioned
anywhere in the paper's install instructions - worth adding a line so readers
don't hit a confusing pip failure. Also found what looks like a leftover
variable-rename bug in contingency.ipynb (cell referencing M200, which is
never defined - I think it should be Mbig per the cell above it); flagged
inline on the notebook.

Novelty and Impact

The paper reads a little ambiguous about which parts are new versus consolidating
prior published methods (most of affinis.associations/proximity/filter) versus
what's actually new here (Forest Pursuit, and MENDR as a shared cross-community
benchmark). I think both are valuable contributions, but a sentence or two
making that split explicit up front would help readers calibrate expectations.

Open questions

Note

Would love your take on these below - not blockers, just things that stood out.

1. The benchmark table shows GLasso beating Forest Pursuit on APS while Forest
   Pursuit wins on MCC. Could a sentence of intuition be added inline for why,
   rather than requiring a trip to the thesis citation?
2. On scalability: my own background is plasma physics, where a natural
   application would be thousands of boolean-ified measurements across tens of
   thousands of experimental shots - well beyond MENDR's current 300-node
   maximum, and squarely in the regime where the dense-kernel step (noted in
   Future Work) would matter most. Has this been tested at that scale, or is
   there a sense of where it would start to strain (memory, runtime, or
   otherwise)? Even a rough sense would help someone like me scope a first
   experiment.
3. Is real-world (non-synthetic) validation on any of the four motivating
   domains planned, or is MENDR intended as the primary validation path?

None of this is blocking at this stage. I'm looking forward to iterating as the
draft develops. I'll add inline comments on the specific lines mentioned above
over the next few days.

[rtbs-dev]

Thanks for the amazing points! I'm working on bumping the python version requirement now, but I'll address each point shortly (another paper deadline internally for me this week 😅 )

[rtbs-dev]

Ok, new patches of affinis and contingency have been published, which broaden the python version requirements (seems like poetry/uv were...quite conservative, by default).

I don't see any inline comments on the review pane, did I miss them?

[rtbs-dev]

@jrbarhydt I'll work on those technical content/novelty comments shortly. As for the "open questions":

1. Very interesting stuff, actually. It turns out you can re-weight the Forest-pursuit edge probabilities to be "interaction probabilities" instead...which is closer to what GLASSO is estimating by default (and is why some folks use Stability Selection to approximate edge probability on top of GLASSO). With a simple re-scaling forest pursuit can meet-or-beat GLASSO's APS, but that comes at the cost of greatly reduced E[MCC]. Basically, APS will be high if there is any threshold where both precision and recall are high, while E[MCC] calculates the expected value over all thresholds. Re-weighting so that rare edges are de-valued can help increase precision at "good" thresholds, but hurts recall throughout.
2. This is super interesting and I would love to talk to you about this more. I think it can absolutely scale (I've actually used it myself on graphs up to around 10k, if I recall). See this notebook for the ongoing work on sparsity speed-ups (I describe a bit more in this issue
3. Most of the real-world validation is hard because we rarely have a "ground truth" dataset to verify edge existence in these kinds of settings. A lot of this is closer to topic modeling or cluster analysis in that you can know that a result "looks good" or "is useful", but rarely are clusters or topics "real" in a measurable sense...unless you've synthesized the data to have that original structure, intentionally. However, I think it would be useful to include in mendr some of the case study graphs e.g. the two here and this one here. Also looking into a real-world validation possibility via the Enron emails dataset, since there's a version of that floating around that preserves the "walk" structure (i.e. the threads, and use it to test reconstruction of power relationships within the organization.

[rtbs-dev]

Update on the sparsity/parallel features for FP, my branch has a working prototype that should be able to handle your use-case. rtbs-dev/affinis#4

[rtbs-dev]

@jrbarhydt As for your point about impact and novelty disambiguation, I'm pretty sure you've got the gist of it, but I can try to maybe add a blurb in the early sections describing what exactly is new? for affinis, it's mainly the architecture and consistent API that is new, since Forest Pursuit was discussed in a prior thesis (and hopefully with more detail and extension in an upcoming journal paper...). However, Forest Pursuit's first implementation is in affinis, so that implementation itself is novel. Does that help?

[jrbarhydt]

@rtbs-dev I did write all that coming off of writing a Journal review, so I had novelty central on my mind. I genuinely do think the gist is covered pretty well. SciPy presentations usually give room for survey and stuff, so I think it's good.

I'll definitely take a look at your blurb on parallelism. Very cool stuff, thanks for sharing.