Hey @SebastianCallh
Is it correct to think “
c
is not directly observed so it should be an argument”?
Yes, that is true. Initially I though there must be a workaround, but there is another restriction for datavar
- the observed value should not change the structure of the model. Unfortunately this is exactly the case for your c
variable as it attempts to change the underlying factor graph of the probabilistic model on the fly. This is not supported.
If that is correct, how would that work in a filtering setting? My end goal with this is to try and write a filtering version of this model, but then
c
has to be a datavar, correct?
Hm, that is an interesting point. As I mentioned it is not allowed to change the graph structure on the fly, so it means that you have to create a new model every time for each of your filtering steps. This also seems valid to me as you indeed have different models if you change c
. It should not be a big problem as creating a model is fast in the ReactiveMP
package.
I must admit it is an interesting use case though and we will think if it possible to support it in the future. You might also take some extra inspiration from this question about multivariate linear regression. It does model \alpha
as a multivariate gaussian, thus does not require the c
parameter.
P.S. Currently our team is working to release a next-gen version of ReactiveMP, which we call RxInfer. RxInfer will include the whole ecosystem ReactiveMP
, GraphPPL
and Rocket
and is aimed to provide a user-friendly inference routines. You might be interested in that since it includes the new inference procedure for the filtering: here is an example. If everything goes according to the plan we release RxInfer at the end of this month.