-
Notifications
You must be signed in to change notification settings - Fork 39
Description
Transferring this from a discussion on the weekly meeting Google Docs: we should split up templated_setindex!! to do two different actions, one to create an empty template in a VNT, and one to set the value of one or more elements. That is, we could have something like this:
vnt = VarNamedTuple()
vnt = DynamicPPL.settemplate!!(vnt, zeros(3, 3), @varname(x))
vnt = BangBang.setindex!!(vnt, 10.0, @varname(x[1,1]))templated_setindex!! I think would still exist, but it would be a composition of the last two lines. The main benefit of doing so is so that we would be able to create preallocated, empty, VNTs prior to the model evaluation, instead of the current workflow where templates are detected at model runtime.
I think this should not be very difficult to do; the main concerns would be type stability, for example in
vnt = DynamicPPL.settemplate!!(vnt, zeros(3, 3), @varname(x))
# string instead of float
vnt = BangBang.setindex!!(vnt, "a", @varname(x[1,1]))the latter call would be type unstable since it would need to broaden the eltype of the array. This is in fact the user's fault for supplying the wrong template, but I guess we would need to make it clear. The reason why templated_setindex!! avoids this type stability issue is because when calling
templated_setindex!!(vnt, "a", @varname(x[1, 1]), zeros(3, 3))it in fact infers the eltype of the array from the value "a" rather than the eltype of the template Float64.