Open cpfiffer opened 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.
Essentially, we generate a Module and use that as a pseudo-function struct
This seems a very surprising and non-standard use of Module
s :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.
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)
I think we might as well implement the safecopy stuff just because it is good practice, but it is no longer a priority.
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 modeldeepcopy
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?