complete: natural-logpdf-clamps-neginf (PyAutoFit#1534)

[Jammy2211]

Summary

Mind state for the last task in the loggaussian-prior-support lineage. Two commits, no code.

1. Filed (6965533). draft/bug/priors/natural_logpdf_clamps_neginf.md — the loose end noted in PyAutoFit#1532's Shipped comment and not filed at the time.

2. Completed (4545add). PyAutoFit#1534 merged as 5c391fd, issue #1533 closed; record written, prompt retired.

What the bug was

AbstractMessage.natural_logpdf called nan_to_num with nan=-inf but default posinf/neginf, so a genuine -inf was clamped to -1.7976931348623157e+308. The call did the opposite of its intent for exactly the inputs that already had the right answer.

The asymmetry is what named the mechanism, on LogGaussianPrior(0.4, 1.3):

message.logpdf(-1.0) = -inf                       # log(-1) is NaN -> nan=-inf applies
message.logpdf( 0.0) = -1.7976931348623157e+308   # log(0) is -inf -> default neginf clamps

Two out-of-support points, two different answers, from one line — and the clamped value is exactly -sys.float_info.max. It matters because that value is finite, and isfinite is what optax.apply_if_finite and non_linear/clipper.py branch on to detect a lane leaving the prior support.

Sweep

draft/research/graphical_ep/transformed_message_declares_support.md carried this as an open, "probably harmless, unverified" observation, and its measurement table's 0.0 row is now stale on main from 5c391fd. Repointed to the fix and the record, with a note to re-run the probe rather than trust the printed value.

The prompt's conclusion is unaffected — EP was protected by the message returning a clean -inf at negative values, which is the row that mattered, not the 0.0 row — so it stays open at its reduced priority rather than being retired.

A process note in the record

complete/2026/08/natural-logpdf-clamps-neginf.md closes with three stale-API misreadings from this session's CI waits, because they cost more time than the fix did. GitHub's PR check endpoints repeatedly served data an hour behind reality, producing one false "stall", one false "no CI configured", and one false hang diagnosis that wrongly implicated the fix itself. The reliable read is list_workflow_jobs with per-step completed_at timestamps, compared against elapsed wall-clock.

Checks

• lifecycle.py check — OK
• lifecycle.py index --check — OK (1160 records)
• intake dashboard --check — dashboard.md + dashboard.html are current

---

Generated by Claude Code