…` submodels Follow-up A of decision 0gt3nbm ("both A and B"), plus two landed defects found while implementing it. ## A — the duplication is gone `ranef_correlated` was still a plate and still had a `ranef_correlated_cv` sibling whose body differed from it in exactly one size expression; the `(1 | g)` fast path had the same pair. That is the "two SLIC models" duplication the user rejected in 2ffac3c, surviving on the other path. `ranef_correlated` is now FLAT (`z_flat` + reshape) and takes `n_groups` as an ordinary kwarg, the shape `ranef_correlated_draws` already had. `ranef_intercept` already took it. So the CALLER picks the size expression -- `n_<g>` ordinarily, `maximum(<g>_idx)` for a group in `cv_groups` -- and one submodel serves both. `ranef_intercept_cv` and `ranef_correlated_cv` are deleted, with their exports. A plate could not do this: StanBlocks' plate branch returns before the `cv ? :quantities : :parameter` decision, so a plate-internal fresh parameter never consults cv at all and a cv outer size silently emits an in-sample block. Going flat also costs nothing now -- StanBlocks 94a71a0 hoists plate loop-invariants itself (snag benchmarked-brm-20aa0361 item 1), which closed about half the measured plate gap, and the residual is the per-call Cholesky logdet a plate cannot avoid at all (item 2, now filed as vectorise-plate-e7151099). EMITTED-STAN CHANGE on the plain path: the sampled parameter is `_z_flat` (`vector[K*G]`) where it was `_b_cols_z` (`matrix[K, G]`), so coordinate NAMES move from `.<t>.<g>` to `.`, i = t + (g-1)*K. Values and column-major layout are unchanged. Consumers going through `ranef_blocks`/`ranef_coordinates` follow automatically. Recompilation is explicitly not a concern (0gt3nbm). ## Two defects this fixes, both pre-existing on the landed tip 570b442 Both from 2ffac3c, which changed the bucket emission without touching src/prediction.jl. Both on the `(… |ID| g)` path this snag exists for. 1. `_RANEF_FAMILIES[:ranef_correlated_draws]` still declared the plate's `b_cols_z`/`:term_group`. Measured: test/probe_prediction_modes.jl FAILS at 570b442 -- "block b_p_subject expects unconstrained coordinates that this model does not have: b_p_subject_b_cols_z.1.1, ...". 2. `ranef_blocks` threw for every cv bucket model. A cv-sized block's `n_groups=` names a Stan-side local (`<binding>_n_g = maximum(<g>_idx)`) -- that indirection is what carries the taint -- and it was looked up as a data key. Measured on a detached worktree at 570b442: "b_p_subject ~ ranef_correlated_draws(...) references data key b_p_subject_n_g, which the model's data does not carry." Resolved by exact name match, so a genuinely missing data key still errors loudly. So the CV artifact emitted correct Stan but could not be addressed post-fit. ## Coverage for the gap that let #1 land The runtime half of probe_prediction_modes.jl does catch #1, but needs BridgeStan and was not run before that landing. It now also asserts each block's `z` against the EMITTED STAN SOURCE at declaration level, with a negative control so `occursin` cannot pass by accident. Added regression tests for the cv bucket case (#2) and for the plain `(… | g)` cv flip to generated quantities, which was the behaviour the deleted `_cv` submodels carried. Also corrected several comments claiming the default emission is byte-for-byte unchanged -- true of the kwargs, no longer true of the plain path. Tests: 10/11 files pass. ranef_cv_centered 84/84, probe_prediction_modes green including the runtime half. plate_stress.jl fails at `using BridgeStan` on line 3 -- not a direct dep of this env, pre-existing, unrelated to this change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QSexZYgHH5BibH8dEjWQ3k

Uh oh!

implement Bijectors interface for distributions #2

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions