Interface for defining which prior log densities are stored for priorsense

[avehtari]

Currently, brms stores all prior log densities in lprior variable. This is fine as the default behavior and makes it easy to use priorsense for quick tests without increasing the memory usage too much. To be able to focus on specific priors, we could allow priors to be tagged with labels.

For example, using a modified version of the example from set_prior doc

make_stancode(rating ~ treat + period + carry + (1|subject),
              data = inhaler, family = cumulative(),
              prior = c(prior(normal(0,10), class = "b", lprior = "b"),
                        prior(normal(1,2), class = "b", coef = "treat", lprior = "treat"),
                        prior(cauchy(0,2), class = "sd", group = "subject", coef = "Intercept"))

This would store the corresponding priors in variables lprior_b and lprior_treat. The same tag could be used for several priors, in which case the log density contributions from those priors would be summed together.

ping @n-kall

[n-kall]

In the separate_scaling branch of priorsense I have implemented the selection of priors and likelihood contributions in the case that lprior and log_lik are arrays. Currently the user needs to keep track of which element of the array corresponds to which prior, but perhaps the mapping can be stored.

[avehtari]

Any update on possible progress on this? More people are using priorsense with brms and hierarchical models, and they get prior-likelihood conflicts reported, and our advice is to choose which priors to scale, but currently it requires editing the Stan code.

[paul-buerkner]

no updates unfortunately. I simply don't have the time myself at the moment. Aki Vehtari ***@***.***> schrieb am Mi., 27. Nov. 2024, 13:32:

…

Any update on possible progress on this? More people are using priorsense with brms and hierarchical models, and they get prior-likelihood conflicts reported, and our advice is to choose which priors to scale, but currently it requires editing the Stan code. — Reply to this email directly, view it on GitHub <#1585 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCW2AAT7LWFJKMINHCJITL2CWUVJAVCNFSM6AAAAABSSUAKZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBTGYZTSMBZGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[avehtari]

Would this be something that someone else could implement? I think your input would be required to decide how the user interface would be like, and of course any guidance on the brms internals would be appreciated

[paul-buerkner]

I like the user interface you proposed in terms of an lprior argument to the prior functions. Internally, upon defining the lprior_ variables one would have to then first identify which parameters belong to which lprior and then add the contribution there accordingly. likely inside the stan_prior function.