Use Stan's "Affine Transformation" syntax

[gowerc]

Stan offers helper syntax to make converting between the centered / non-centered parameterisations smoother. That is instead of

parameters {
    vector[K] beta_raw;
}

transformed parameters {
    vector[K] beta;
    beta = mu_beta + sigma_beta * beta_raw;
}

model {
    beta_raw ~ std_normal();
}

You can specify the identical model as:

parameters {
    real mu_beta;
    real<lower=0> sigma_beta;
    vector<offset=mu_beta, multiplier=sigma_beta>[K] beta;
}

model {
    beta ~ normal(mu_beta, sigma_beta);
}

Whilst not the clearest of syntax's this has the added benefit of being almost identical to the centered parameterisation setup which is just:

parameters {
    real mu_beta;
    real<lower=0> sigma_beta;
    vector[K] beta;
}

model {
    beta ~ normal(mu_beta, sigma_beta);
}

If we were to adopt this syntax it would in theory GREATLY reduce the amount of conditional Jinja code that we have within our Stan files hopefully making them much easier to manage.

See https://mc-stan.org/docs/reference-manual/types.html#affine-transform.section

Only downside to this is that it would mean we need to convert all of our parameters to be on the log-scale (currently they are on the "regular" scale) which might be a pain in terms of updating all our test code / priors and documentation accordingly. Considering @danielinteractive & @mercifr1 are currently rolling out training it may be best to wait until that is finished ?

[danielinteractive]

Thanks @gowerc for the heads up, yeah, we will have the first session in 6 days, I guess it would be better to wait until after that at least, since this would be a breaking change. Once this happens, we could update the session material.

[gowerc]

As an aside, my initial testing on a simple normal model showed that using their helper syntax also gets a nice performance bump; 10seconds -> 6seconds in my toy example; though it would be no where near this for jmpost as most of the run time for us comes from the Gaussian quadrature approximation and the non-linear function evaluation which this doesn't affect. But still nice to know there is also a small performance bump as well.