Compatibility with Turing models syntax?

[DominiqueMakowski]

Looking at some of the examples of model specification in RxInfer (in particular "simple" ones like a linear regression), it seems that the syntax for both packages is not so distant, for example

# RxInfer
@model function linear_regression(nr_samples)
    intercept ~ Normal(mean=0.0, variance=1.0)
    beta ~ Normal(mean=0.0, variance=100.0)

    x = datavar(Float64, nr_samples)
    y = datavar(Float64, nr_samples)

    y .~ Normal(mean=intercept .+ x .* beta, variance=1.0)
end


# Turing
@model function linear_regression(y, x)
    σ² ~ InverseGamma(2, 3)  # Sigma
    intercept ~ Normal(0, sqrt(3))  # Intercept
    beta ~ TDist(3)

    y ~ Normal(intercept .+ x .* beta, σ²)
end

(the only (?) difference here being the datavar data type specification)

Thus, I was wondering if there were any long-term plans to bring the two syntaxes even closer, and work towards some degree of compatibility. From a user perspective, it would be simply amazing to be able to specify a model and be able to run inferences via Turing or RxInfer.

Thanks for your work!

[wouterwln]

Hi, first of all, thanks for trying out RxInfer.jl, your feedback means a lot to us!

Coming to your question, we are currently working on a new implementation of our model specification, one that would remove datavar and similar statements from our language and which would therefore resemble the mathematical representation of a model (which is what Turing is also striving for). In that sense you could say that the model syntax for both packages will be even more similar in the not-too-distant future. However, it is important to notice that both RxInfer.jl and Turing.jl have their own implementation of this language (in GraphPPL.jl and DynamicPPL.jl respectively), and therefore the "mix-and-match" behaviour you suggest will not be possible. Both @model macro's exported by both packages are a simplified interface to a quite complex machinery of model construction that is tailored to the requirements of their respective inference package. This would, next to causing an obvious naming collision for the @model macro, mean that you'd have to re-run the model macro for the specific package you'd like to do inference with, and write the rest of the inference procedure as you'd normally do in either package. I'm afraid the mix-and-match behaviour I think you're aiming for is simply not possible (unless at some point there is a unifying backend PPL that both languages use).

[DominiqueMakowski]

I see, thanks for the clarification! Looking forward to see how this evolves :)