How to handle discrete parameters? about posterior HOT 9 OPEN

I agree but how would their treatment be different?

from posterior.

You cant use mean, rhat or sd for example.

We would probably need to define ordered and non-ordered representations.

I actually dont know how to summarize them in a good way?

from posterior.

I see. At least anything that has more than 2 unordered values will be a problem.
Summarizing them would come down to making a table of their values mostly I think.

For ordered ones, median etc. would still be useful.

I agree this is something worth considering and it certainly requires some thought of how to do this correctly.

from posterior.

Indeed. I guess that we may be a little blind by the stan limitations here. I think a posterior package should at least don't break using discrete parameters.

from posterior.

Does anybody know how other packages handle those?

from posterior.

I do not know. I know JAGS has discrete parameters.

from posterior.

@MansMeg Thanks for raising this issue. This is definitely something we should think about.

Maybe the easiest thing to do for now is to just to include discrete parameters like all others but print a message if we detect a discrete parameter that certain summaries/diagnostics do not apply? I'm certainly open to other options though!

from posterior.

Some thoughts here:

• from what I remember of JAGS (it's been a few years) it just uses integers for discrete parameters. That seems fine enough for most use cases. The only case where it is annoying is if those integers actually correspond to something meaningful, like factor levels in the original data.
• in some cases tidybayes will give you back factors if there's enough information from the model to do it. E.g. if you use add_predicted_draws on an ordinal regression from brms you will get factors (you could have, for example, a long-format data frame with a factor column representing posterior predictions). This can be very useful in summarizing predictions or creating visualizations, particularly because manually mapping integers back onto levels may be error prone.

If we wanted to support factors life can get complicated for some formats: e.g., I think matrices of factors break in some corner cases. Other formats, like lists and tibbles, should be fine. As I've been experimenting with rv-style formats (#8), one potential advantage of some ways of structuring it is that you can construct distributions over arbitrary objects. This makes it less efficient in some cases but could be a way to allow that flexibility (traded off against efficiency) if someone wants it.

So I guess one question is, do we want to support something (e.g. samples of factors) that can only really be represented in some formats and not others?

from posterior.

I think supporting importants things only in certain formats is fine, and I would consider discrete variables to be one of those important things. We need to find an efficient way to detect their presense and then throw an error if an attempt is made to convert to a format which doesn't support them, but that should be no problem.

from posterior.