EventBuilder and record_winner/record_draw cannot set prior or drift_scale
rayon becomes a default-on feature
posterior_of queries re-pay the full O(n^3) solve
Shipped in 0.7.0 and wired up here. Measured on the real export, round-grain connectivity — 11 competitors, 55 pairs:
379 variables
factorise 4.3 ms
55 queries 1.6 ms (~29 us each)
-----…
posterior_of queries re-pay the full O(n^3) solve
Released in 0.7.0, on the registry now.
Minor rather than patch: History::joint, Joint and Joint::variables are new public surface. Nothing was removed and no existing signature…
posterior_of queries re-pay the full O(n^3) solve
posterior_of queries re-pay the full O(n^3) solve
Implemented, on feat/joint-handle. Not merged or released yet.
Thank you for the flat four-solve trace — that is the measurement that makes this a bug report rather than a feature request, and…
cdf is pub(crate), so callers approximate it with a z-multiplier
Adopted in lester-stash on 0.5.0 — thank you. One correction to this issue, since the reasoning in it was partly wrong and I'd rather not leave that standing.
**The claim that a z-band "silently…
posterior_of queries re-pay the full O(n^3) solve
Correction to the figure above, and a finding that is probably more useful than the original request.
I said our 90-cell grid is "about nine minutes". That is wrong. It took the 6 s rate from…
posterior_of queries re-pay the full O(n^3) solve
Run against 0.6.0. All 55 pairs resolve, and the answer is that my 1.30 was wrong — the marginal was already right.
The number
exact / marginal, 55 pairs, real export: 1.035
So…
Closing as delivered — and no follow-up issue is needed, because the slice question is fixed rather than deferred.
0.6.0 makes the joint time-expanded: one variable per appearance,…
Fixed in 0.6.0. The latest-slice limitation was my mistake, not a documentation gap, and your measurement is what caught it.
What was wrong
I built the joint over a single slice and…