Turing.jl Newsletter 17
VarNamedTuple
We have been working on a really complete overhaul of the internal VarInfo data structure (several thousand lines of code changes). Pretty much the entire thing has been rewritten from scratch. There are still a number of kinks to iron out, but CI is passing, so there is nothing really fundamental blocking it, just more test coverage and handling of edge cases, and checking that it doesn’t break anything in Turing.
What you’ll get out of it:
More internally consistent indexing behaviour: if you have something like
x ~ MvNormal(zeros(2), I)and you condition your model onDict(@varname(x[1]) => 1.0, @varname(x[2]) => 2.0)it will now behave correctly (previously the conditioning would have no effect). Colons also benefit a lot from this. Essentially, if I’m not wrong, every item in the table in this issue will more or less become true.Generic AbstractArray support: you should be able to use OffsetArrays, DimArrays, etc. and have them ‘just work’ the way you expect them to. For example you should be able to do
dimarr[X(1), Y(2)] ~ distand it should behave just as if you wrotearr[1, 2] ~ dist.Much improved performance on many common operations (see this PR for some benchmarks).
If you develop against DynamicPPL, all our VarInfo subtypes are unified now, there’s no longer a distinction between ‘typed’, ‘untyped’, or ‘simple’ VarInfo.
If you’re interested in a behind-the-scenes look at why and how we did this, there are some docs here (still in progress, but a lot of the basics are covered)! The performance aspects will mostly affect non-HMC/NUTS samplers (since Turing@0.42 / DynamicPPL@0.39, HMC and NUTS almost completely don’t use VarInfo anymore), although the correctness aspects will apply to every Turing model.
Back to top