@@ -1200,15 +1200,24 @@ function predict(
1200
1200
varinfo = DynamicPPL. VarInfo (model)
1201
1201
return map (chain) do params_varinfo
1202
1202
vi = deepcopy (varinfo)
1203
- # TODO (penelopeysm): Requires two model evaluations, one to extract the
1204
- # parameters and one to set them. The reason why we need values_as_in_model
1205
- # is because `params_varinfo` may well have some weird combination of
1206
- # linked/unlinked, whereas `varinfo` is always unlinked since it is
1207
- # freshly constructed.
1208
- # This is quite inefficient. It would of course be alright if
1209
- # ValuesAsInModelAccumulator was a default acc.
1210
- values_nt = values_as_in_model (model, false , params_varinfo)
1211
- _, vi = DynamicPPL. init!! (rng, model, vi, ParamsInit (values_nt, PriorInit ()))
1203
+ # TODO (penelopeysm): BEWARE - Because `ParamsInit` expects unlinked
1204
+ # values, this is bugged in the case where `params_varinfo` is linked.
1205
+ # This could be solved by using `values_as_in_model`. However, we run
1206
+ # into another problem:
1207
+ # - The `model` passed into this function will have the target
1208
+ # prediction variables (say `y`) set to `missing`.
1209
+ # - Calling `values_as_in_model` on this new model will lead to
1210
+ # DynamicPPL attempting to extract the values of `y` from the
1211
+ # `params_varinfo`, which will fail since `y` will not have been
1212
+ # present.
1213
+ # I think that the solution is to pass in the ORIGINAL model, but ALSO
1214
+ # pass in a set / iterable of VarNames that are to be predicted against.
1215
+ # That way, we can:
1216
+ # - Safely use `values_as_in_model` to extract a dict of values.
1217
+ # - Drop the values of the prediction variables from the dict.
1218
+ # - Then use `ParamsInit` to generate the predictions.
1219
+ values_dict = values_as (params_varinfo, Dict{VarName,Any})
1220
+ _, vi = DynamicPPL. init!! (rng, model, vi, ParamsInit (values_dict, PriorInit ()))
1212
1221
return vi
1213
1222
end
1214
1223
end
0 commit comments