You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
julia>using DynamicPPL, Distributions
julia>@modelfunctionf()
x = (a=1, b=2)
x.a ~Normal()
x.b ~Normal()
end
f (generic function with 2 methods)
julia>values_as(VarInfo(f()), NamedTuple)
(var"x.a"=-0.2067696145335533, var"x.b"=-2.788035859751896)
I would have liked (x = (a = ..., b = ...),).
Same thing happens with arrays:
julia>@modelfunctionf()
x = [0.0, 1.0]
x[1] ~Normal()
x[2] ~Normal()
end
f (generic function with 2 methods)
julia>values_as(VarInfo(f()), NamedTuple)
(var"x[1]"=-0.9522900124219256, var"x[2]"=0.626145525096277)
I do realise this is a very non-trivial thing to fix, because of the general problem that we can't reconstruct shape from a list of varnames; but I feel like it's at least worth having a(nother?) think about it. In particular, I'm still wondering about having varnames carry info about their shape, or maybe the varinfo can even maintain a full mapping of variables that are in scope along with their values.
I suppose there are some pathological cases that can break this very idealised situation.
@modelfunctionf()
x = [0.0, 1.0, 2.0]
x[1] ~Normal()
x[3] ~Normal()
endvalues_as(VarInfo(f()), NamedTuple)
# how many entries of x should this return?
See also the last time I suggested it here #712 (comment)
The text was updated successfully, but these errors were encountered:
The other radical proposal that I could get behind could be to just forbid NamedTuples entirely and only use OrderedDict for everything (e.g. conditioning, initialising values, ...) or maybe NamedTuple can be kept as a thin user-facing layer, but internally it always gets converted to OrderedDict before being passed into DynamicPPL internals. e.g. for condition,
I would have liked
(x = (a = ..., b = ...),)
.Same thing happens with arrays:
I do realise this is a very non-trivial thing to fix, because of the general problem that we can't reconstruct shape from a list of varnames; but I feel like it's at least worth having a(nother?) think about it. In particular, I'm still wondering about having varnames carry info about their shape, or maybe the varinfo can even maintain a full mapping of variables that are in scope along with their values.
I suppose there are some pathological cases that can break this very idealised situation.
See also the last time I suggested it here #712 (comment)
The text was updated successfully, but these errors were encountered: