Currently implemented operations on Turing models:
- fix / unfix (equivalent to the do-operator)
- condition / decondition
- generated_quantities
- predict ( could be implemented using fix, see PR)
@model function demo1()
x ~ Normal()
z ~ Normal()
y = x - z
return y
end
m = demo1()
conditioned_m = condition(m, (x=1))
fixed_m = fix(m, (x=1))
ret = generated_quantities(m, (x=1.0, z=2.0))
predict(m, chain)
Proposed new model operation
This will replace and unify two current syntax submodel and generated_quantities. A reviewer for a Turing.jl preprint has pointed out that the generated_quantities is confusing due to the name clash with Stan's generated quantities block, but with different motivations (Stan's generated quantities are entirely motivated for performance while ours is a return statement that can be used for many purposes).
Another consideration is that submodel and generated_quantities have almost identical semantics from the user's perspective: both syntaxes obtain the returned variables of a model. However, the submodel syntax requires some special treatment for inference purposes, i.e., storing all submodel random variables in the parent model's VarInfo. This distinction doesn't matter much for users and won't deserve two separate syntaxes.
@model function demo2a(x, y)
@submodel a = demo1(x)
return y ~ Uniform(0, abs(a))
end
# with the proposed syntax, this becomes:
@model function demo2b(x, y)
a = @returned_quantities(demo1())
return y ~ Uniform(0, a)
end
In addition, the generated_quantites becomes
returned_quantities(model::Model, parameters::NamedTuple)
returned_quantities(model::Model, values, keys)
Currently implemented operations on Turing models:
Proposed new model operation
returned_quantitiesThis will replace and unify two current syntax
submodelandgenerated_quantities. A reviewer for a Turing.jl preprint has pointed out that thegenerated_quantitiesis confusing due to the name clash with Stan's generated quantities block, but with different motivations (Stan's generated quantities are entirely motivated for performance while ours is a return statement that can be used for many purposes).Another consideration is that
submodelandgenerated_quantitieshave almost identical semantics from the user's perspective: both syntaxes obtain the returned variables of a model. However, thesubmodelsyntax requires some special treatment for inference purposes, i.e., storing allsubmodelrandom variables in the parent model'sVarInfo. This distinction doesn't matter much for users and won't deserve two separate syntaxes.In addition, the
generated_quantitesbecomes