TuringLang / AbstractMCMC.jl

Abstract types and interfaces for Markov chain Monte Carlo methods
https://turinglang.org/AbstractMCMC.jl
MIT License
87 stars 18 forks source link

Error when using MCMCEnsemble on models containing Module types #89

Open cpfiffer opened 2 years ago

cpfiffer commented 2 years ago

Originally detected in https://github.com/HighDimensionalEconLab/HMCExamples.jl/issues/28.

Essentially, we generate a Module and use that as a pseudo-function struct, but its inclusion in the model means that the model deepcopy

https://github.com/TuringLang/AbstractMCMC.jl/blob/56431bd4298bac6ad324dd47dc3162cf49c45626/src/sample.jl#L305

fails as Module cannot be deepcopied. Unfortunately it's a little tricky to detect this kind of weird case in advance. Perhaps it would be nice to add keywords disabling any of the deepcopy calls for users who don't mind so much?

cpfiffer commented 2 years ago

This is kind of a RFC, by the way -- I'm not sure if there's a better way than a keyword argument.

devmotion commented 2 years ago

Essentially, we generate a Module and use that as a pseudo-function struct

This seems a very surprising and non-standard use of Modules :eyes:

Maybe we do something similar to what we do in SciML (https://diffeq.sciml.ai/stable/features/ensemble/) and support to specify if a safety deepcopy of the model and sampler are called and what reduction function should be used.

wupeifan commented 2 years ago

Our current solution is to override the deepcopy of modules by passing the references only, which is fine for now (i.e., overriding this line https://github.com/JuliaLang/julia/blob/master/base/deepcopy.jl#L33); whether deepcopying a module is a good move or not is up to you guys, but this issue (I think) is temporarily resolved. (See https://github.com/HighDimensionalEconLab/DifferentiableStateSpaceModels.jl/issues/70)

cpfiffer commented 2 years ago

I think we might as well implement the safecopy stuff just because it is good practice, but it is no longer a priority.