That’s what JAGS and BUGS do. They just define the model as a directed acyclic graph and you determine what’s data at runtime.
Right—just need them to be defined before they’re used.
I think this is also what Michael was objecting to when Andrew wanted to write
real mu ~ normal(0, 5);
The only separation required is that things are defined before they are used. In that sense, the priors in some sense really do come before the sampling distribution, because the parameters defined by the prior are used as arguments to the sampling distribution. Of course, Stan as it is now, just collapses all this into a single log density definition with no ordering requirements because the parameter values come in from the algorithms.
I don’t know what this would mean. The transformed data and transformed parameters blocks are where you transform data and parameters. Did you have an example in mind?
That’s not how I view it at all. It’s generally good practice in programming to declare variables near where they are used. This is trying to solve the problem of users forgetting to include priors and needing to continually go back-and-forth between the parameters block and model block to line things up.
That was my goal all along, for instance with typing. But it falls down in not allowing compound declare/distribute functions to keep declarations near usage.
Yes. Mitzi’s just finishing up refactoring the underlying type system to open the way for new types beyond
matrix. Tuples will be first, but I’d also like to add simple functional types (like typed lambda calculus rather than the untyped form you see in Lisp or the loopy typing you see in something like ML).
I think that’s a legitimate concern for
real(0, ). But you also have to keep in mind that adding verbosity can reduce clarity because it makes the code hard to scan. This is why I’m always harping on about formatting.
I didn’t intend to promote that idea! What is emerging is that we’re trying to deal with a conflict between:
Exactly as Jonah says.