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

(Possibly) get rid of transitions altogether 😱 #149

Open
penelopeysm opened this issue Oct 21, 2024 · 1 comment
Open

(Possibly) get rid of transitions altogether 😱 #149

penelopeysm opened this issue Oct 21, 2024 · 1 comment

Comments

@penelopeysm
Copy link
Member

penelopeysm commented Oct 21, 2024

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:

  1. step would return only one value, which is the state;
  2. bundle_samples would probably be modified to take a vector of states rather than a vector of transitions.
  3. 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.)
  4. 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.)

@torfjelde
Copy link
Member

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

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

No branches or pull requests

2 participants