Bounds and priors for generalized logit link

[reedorchinik]

Hi, thanks for creating such a great package!

I'm fitting a hierarchical model with a regressor for v (and eventually a regressor for z). I am using safe priors with the "log_logit" link setting and need to use an approximately differentiable likelihood (or I receive max_treedepth warnings). Code here:

model = hssm.HSSM(
data=df,
hierarchical = True,
link_settings = "log_logit",
loglik_kind = "approx_differentiable",
include = [
{
"name": "v",
"formula": "v ~ 0 + truth + (0 + truth | participant_id)"
}
]
)

With this combination of settings, each variable is modeled using a generalized logit link with explicit bounds rather than the combination of identiy (v), log (a and t), and logit (z) links when using either analytical or blackbox likelihoods. The model set up is shown below. All priors, links, and bounds are the default. The bounds appear identical to the bounds for "identity" links.

When I fit this model, many of the r hats are quite large. The z_Intercept value is hugging 0 (posterior shown below) which makes me think that the explicit bounds are not in probability space but rather logit space.

Does it make sense to use the combination of "log_logit" links, safe priors, and an approximately differentiable likelihood? Do I need to change the explicit bounds? More generally, is there a reason that the "log_logit" links are different when using analytical vs blackbox vs approximately differentiable likelihoods?

Thanks!

[AlexanderFengler]

Hey @reedorchinik,

sorry for the late response here.

One things that immediately pops out, is that the bounds for z, given the approx_differentiable setting should not be [0,1] but rather something like [0.1, 0.9]. I will open an issue for that right away.

This could already be the root of the problem.

In general the bounds should be 'checked' internally after the link function is applied (so they should not be applied in log space). I will double check if this could be an issue, but it's less likely to be the problem here.

If you look at the trace, do you see that the chain is initially stuck around 0, and eventually starts moving away?

Best,
Alex