-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
submodel
and generated_quantities
operations on models
#691
Comments
There's a big discussion that seems very relevant here: #589 But the syntax you propose is not possible to achieve. It would have to be a macro, unless we want to start messing with function calls in a model, which really doesn't seem like something we want to do 😕 |
I am aware of this. It is easily approachable by replacing all |
Closed in favour of the following revised proposal (copied from #696 (comment)) # To be implemented now
returned(model_instance, chain) # Replaces generated_quantities(model_instance, chain)
x ~ to_sampleable(returned(submodel_instance))
x ~ to_submodel(submodel_instance) # short-hand for the above
# To be implemented some time in the future
x ~ to_distribution(returned(submodel_instance))
x ~ to_sampleable(latent(submodel_instance))
x ~ to_distribution(latent(submodel_instance)) |
Currently implemented operations on Turing models:
Proposed new model operation
returned_quantities
This will replace and unify two current syntax
submodel
andgenerated_quantities
. A reviewer for a Turing.jl preprint has pointed out that thegenerated_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
andgenerated_quantities
have almost identical semantics from the user's perspective: both syntaxes obtain the returned variables of a model. However, thesubmodel
syntax requires some special treatment for inference purposes, i.e., storing allsubmodel
random 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_quantites
becomesThe text was updated successfully, but these errors were encountered: