David Widmann
David Widmann
One consequence of (1) is that many users will run into warnings about conflicting exports and many scripts and tutorials will can't be used with newer Turing versions - `AbstractMCMC.sample`...
> while at the same time allowing Turing.sample (whatever this method is) to add Turing's bells and whistles, e.g. My premise was that these would have to be removed or...
I assumed that `Model
My feeling was that they can easily be kept by changing the upstream code a bit. After all, it seems the only Turing-specific keyword arguments are `chain_type = Chains` and...
The variable names? Isn't that done by `save!!` and `bundle_samples`? We can also prescribe the priority of arguments by defining eg ```julia default_chain_type(model, sampler) = default_chain_type(sampler) default_chain_type(sampler) = Any ```...
> Aye, but on what do we dispatch `bundle_samples` if we remove `InferenceAlgorithm`? On `DynamicPPL.Model`? As suggested in the previous comment, we could work around ambiguity issues by not dispatching...
If the official API/docs state that you must not do this, it's a bug in the sampler package :shrug:
No, I meant a different approach - the one outlined for `default_chain_type` above.
You can define `default_chain_type(::MySampler) = Chains`, can't you? But since it's just a default value anyway and users are free to specify any other value, my feeling is that it...
> transforming the variables back to the constrained space Maybe a side remark but should that really be done in `bundle_samples`? Such transformations mean also that the iterator and transducer...