I think we need a roadmap at a slightly lower level of granularity to understand the flow of PRs.
I would be more comfortable if we developed one of these covariance functiosn to completion—that is we work depth first on the first one, then when that one’s done to everyone’s satisfaction, model the remaining ones after the first one.
It goes through with PRs just like everything else. The doc sources are in
stan-dev repo under
No worries—it took me a few passes to get it into my head what the abstraction was and then several more passes to get it implemented.
This we can do moving forward. It’ll be easier if we get functional types and lambdas into Stan itself.
Same with a lot of the other things and ragged arrays.
It’ll probably be at least a year until we get either of those—@mitzimorris will be working on them after the refactor gets finished (hopefully soon).
Thanks for laying out how to probe memory. This calculates the amount of memory used in our arena, which is the relevant location.
var is a simple pointer to implementation. Because there are no virtual methods, it takes up exactly one pointer (8 bytes everywhere we run). Also, we only use
var on the stack—they’re never allocated on the heap.
vari on the other hand, all have a vtable pointer (virtual chain() method means it’s virtual), a value and an adjoint, so are minimum 24 bytes and are allocated in our arena.