Closed donhausk closed 2 years ago
It seems this is a duplicate of https://github.com/TuringLang/Turing.jl/issues/833? As @mohamed82008 mentioned there, I guess one has to be careful to cache only variables that
only depend on parameters that are not updated in the current Gibbs inner iteration.
It seems that's not guaranteed by the approach you outlined above?
I mean as a hack, I can expose @sampler()
in TuringLang/Turing.jl#965 which lets the user access spl
and do whatever he/she wants. Of course, the caching and guarantee that some computations only depend on some variables will be on the user.
Done.
In your code, you can do:
spl = @sampler()
if :x in spl.alg.space || :y in spl.alg.space
# Compute var
cache["var"] = var
else
var = cache["var"]
end
Out of curiosity, why is @sampler
a macro?
Thanks a lot for your comments!
Out of curiosity, why is @sampler a macro?
Just because it is harder to overwrite a macro by mistake. This use case is rare enough that reserving a variable name for it inside the model body is a bit much imo. The macro is also defined in Turing and exported such that if used outside the model macro, it will error saying that this is only for use inside the model body.
Ah I see :+1:
Otherwise maybe one could define a macro @model_with_sampler
that does basically the same as @model
but also reserves the variable name sampler
inside the model body. I'm not sure though if I would prefer that over a @sampler
macro :man_shrugging:
Closed in favour of https://github.com/TuringLang/AbstractPPL.jl/pull/44
I want to use Turing for the GP-SSM model, which is based on the PGAS algorithm. The implementation is actually straight forward thanks to Turing. However, I have noticed that the Gibbs sampler runs the whole model for every subsampler. For large models this implies that there is a huge computational overhead. One way to solve this issue would be by implementing some "hacky" macros, like:
which would be changed to something like :
This makes the model rather difficult to design because it might not be obvious what belongs inside the brackets and what not. @torfjelde had the idea to do something like the following instead :
which would be changed to something like :
I am anyway planning to implement this macro for my own use and I was thinking that this might be interesting for Turing in general. What do you think?