FIX: Update truncate_arrays
and optimal_parameters
to allow some zeros
#122
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Users who had any zeros in their initial parameters would see an error when calling
optimal_parameters
ending in:The trace and lnprob arrays are initialized to zeros, so an intermediate trace or lnprob will be back-padded with zeros. This issue (and a corresponding issue in
truncate_arrays
) was caused by the code for finding the last iteration checking thatall
parameters were non-zero, when a more appropriate heuristic for finding the last iteration is to check thatany
parameters are non-zero. Note thattruncate_arrays
would fail silently, removing all the iterations from the trace (and probability, if passed). This is fixed so if some parameters are zero,optimal_parameters
andtruncate_arrays
still work. Doctests were written for each to prevent regressions.This issue could occur if an initial parameter passed by a user was zero, since the chains in the ensemble for that parameter are all initialized to zero and any StretchMove made by emcee for that parameter will also produce a zero. This is still allowed, however a warning is now logged so users have feedback on this nuance. The logged warning suggests to provide an initial parameter value that's either a good guess or close to zero.
A future solution would be to give users more flexible options for initializing parameters, such as the system for prior specification. Until a better solution exists, a user who desire parameter values centered at zero could work around this by providing a
restart_trace
(see the input YAML docs) that was made by hand, where the last iteration (just one iteration is sufficient) with all the chains they desire. Each parameter could be initialized to any distribution, for example a normal distribution centered at zero with a standard deviation of 10,000 J.