You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At today's Turing.jl catchup we discussed the possibility of removing transitions altogether. The reason for this is because the sampler state usually contains all the information required to generate the transition, i.e., the transition contains redundant information and adds unnecessary complexity to the implementation. Concretely, this would mean that:
step would return only one value, which is the state;
bundle_samples would probably be modified to take a vector of states rather than a vector of transitions.
The sampler implementation would be responsible for making sure that there are methods to extract a namedtuple of parameters, logp, or any other quantity that needs to be calculated, from a state rather than a transition. (This is pretty much getparams from Add getparameters and setparameters!! #86.)
Plus more stuff needs to be changed, but that will probably become clearer as we work on it.
At today's Turing.jl catchup we discussed the possibility of removing transitions altogether. The reason for this is because the sampler state usually contains all the information required to generate the transition, i.e., the transition contains redundant information and adds unnecessary complexity to the implementation. Concretely, this would mean that:
stepwould return only one value, which is the state;bundle_sampleswould probably be modified to take a vector of states rather than a vector of transitions.getparamsfrom Addgetparametersandsetparameters!!#86.)(FWIW, I'm very much in favour of this.)