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.
(FWIW, I'm very much in favour of this.)
The text was updated successfully, but these errors were encountered:
step would return only one value, which is the state;
I think I'm also in favour of doing this tbh. Though I like the idea of having one representation that is "consumable by the end user" (i.e. transition), I think the added complexity (both for the implementer and the user) is not worth it. I think it'll be easier to provide the end-user some ways of interacting with the resulting state rather than having to explain both the return-values and how to interact with those.
However, I think it would be nice to have @devmotion 's input on this, since he is the core-est of the core maintainers of AbstractMCMC.jl. I believe he's on vacay until 28th Oct, so wee should probably wait until then to actually merge any such changes (though I'm very pro starting the work asap, and then we can just have it ready for his input when he gets back).
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.getparams
from Addgetparameters
andsetparameters!!
#86.)(FWIW, I'm very much in favour of this.)
The text was updated successfully, but these errors were encountered: