"ordered" vector in Stan not strictly ordered

I specified a hierarchical (extended) signal detection model where I parametrized multiple, ordered decision criteria (cr1, cr2, cr3; cr1 < cr2 < cr3) through an ordered vector in Stan. When fitting the model using Cmdstan with a large number of samples (4 chains, 10000 samples each) on a dataset of about 450 participants, about 35 samples contained some participant level samples of the ordered vector that were not strictly ordered (i.e., cr1 = cr2, or cr2 = cr3).
However, I only noticed this when I tried to apply bridgesampling to the posterior samples where I got the following error message:

“Error in object@.MISC$stan_fit_instance$unconstrain_pars(pars) :
Exception: Error transforming variable limits_ind: stan::io::ordered_unconstrain: Vector is not a valid ordered vector. The element at 2 is 0.613933, but should be greater than the previous element, 0.613933 (in ‘model31487641bc0_C_DPSD_new_param’ at line 140)”

For the mentioned vector (more specifically a matrix containing ordered parameters for all 450 participants), about 35 samples do not satisfy the strict order constraint for one individual parameter vector (i.e., at least two elements of the vector are equal).

Meanwhile, the Stan documentation states that “ordered” specifies a strictly ordered vector (10.6 Ordered Vector | Stan Reference Manual).

I am thankful for any hint as to a) why some samples do not satisfy the specified constraint and b) why I can’t apply bridgesampling if the constraint is not satisfied - and of course for ideas on how to solve this!

Relevant part of the Stan code is below - I can also try to provide a reproducible example of this error but this will be difficult since this issue only seems to occur very rarely.

parameters {
    ordered[3] Mu_limits;
    vector[3] Sig_limits;
    // individual parameters
    ordered[3] limits_ind[nsubj];

model {
    Mu_limits[1] ~ normal(-0.5, 0.5);
    Mu_limits[2] ~ normal(0, 0.5);
    Mu_limits[3] ~ normal(0.5, 0.5);
    to_vector(Sig_limits) ~ inv_gamma(2, 3);

    for (i in 1:nsubj) {
        for (l in 1:3) limits_ind[i, l] ~ normal(Mu_limits[l], Sig_limits[l]);
1 Like

You are probably saving the default number of digits, ie 6, in CSV file, and that rounding is causing the problem. See sig_figs in Run Stan's MCMC algorithms — model-method-sample • cmdstanr

(positive integer) The number of significant figures used when storing the output values. By default, CmdStan represent the output values with 6 significant figures. The upper limit for sig_figs is 18. Increasing this value will result in larger output CSV files and thus an increased usage of disk space

We are looking into binary file formats, which would not have this problem


Thank you, that seems to be the issue! Will try it out over the weekend.

1 Like