Hi, see responses below.

Andrew

andrewgelman:

but in the meantime I’ll take what I can get, which is why all avenues are important, including brute force, approximate models, and approximate algorithms.

How is this not saying do them all at once?

I do want to do all these at once, but as part of solving this problem, not as part of core Stan. Considering the three items I listed above:

(a) Brute force: That’s existing Stan features such as MPI and GPU, and to-be-implemented features such as improved adaptation and hard-coding of certain hierarchical models.

(b) Approximate models: That uses existing Stan also. “Approximate models” is what people do all the time, when they want to fit big model X, but that would be too slow so they fit smaller model Y.

© Approximate algorithms: The plan is to implement these outside of Stan (with the exception of ADVI which is already in Stan), for example in R calling Stan, and then if they work well on these real problems, we might want to put them into Stan or build more formal R and Python wrappers for them.

I think it’s ok to do (a), (b), and © at once:

(a) is already being done by Stan developers

(b) is already being done by Stan users

© we will do as needed

andrewgelman:

The reason I’d like to fit the Monster model

We’re blocked on that because nobody other than you understands the model or the data. If you can write the model down as a sequence of sampling statements (LaTeX or chalkboard is fine) and write the diff eqs down, and you can get the data into an R list, then I’d be happy to code it and fit it.

It might make sense for me to do this with Charles when he returns in the fall, as he has experience with these differential equation models.

andrewgelman:

The birthday model is another popular example,

I’m not sure how to measure popularity, but setting that aside, we just need programming effort in order to be able to scale GPs. The design’s been done since last summer in Helsinki.

Then there was the approximation that Aki’s team was working on. Did you not like that one? It could fit the birthday problem in Stan, just not the exact same GP.

Aki and I discussed this. It’s not urgent, we can just talk about it during our next visit to NY.

Anyway, my basic point is that we can’t work on every avenue—we need to prioritize. Personally, I’d rather prioritize the engineering we know how to do, like scaling GPs. I’m not sure what Andrew wants to prioritze.

I support your thoughts on priorities for Stan engineering. I also like application-driven projects. There are people whose focus it is to get these hierarchical models running faster, they can do what is necessary. If at some point there are internal Stan improvements that could help a lot, then we could discuss priorities. But at this point I think that the scheduled improvements in Stan computing and Stan language will help in this and other problems.