Skip to content
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

Closed
yebai opened this issue Oct 15, 2024 · 3 comments · May be fixed by #696
Closed

submodel and generated_quantities operations on models #691

yebai opened this issue Oct 15, 2024 · 3 comments · May be fixed by #696

Comments

@yebai
Copy link
Member

yebai commented Oct 15, 2024

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

  • returned_quantities

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)
@torfjelde
Copy link
Member

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 😕

@yebai
Copy link
Member Author

yebai commented Oct 15, 2024

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 returned_quantities calls with @returned_quantities as part of the @model transformation if we want. I don't think the issue is the difficulty of implementation, but rather, it is if we wish to abuse the function call syntax slightly. I can see the arguments for preferring not to go down that route; if so, we can use @returned_quantities instead of returned_quantities in the above example.

@yebai
Copy link
Member Author

yebai commented Nov 25, 2024

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))

@yebai yebai closed this as completed Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants