State.robustlyCalcPosterior() calls store(-1) internally before recalculating the posterior:
public double robustlyCalcPosterior(final Distribution posterior) {
store(-1);
setEverythingDirty(true);
checkCalculationNodesDirtiness();
final double logLikelihood = posterior.calculateLogP();
setEverythingDirty(false);
acceptCalculationNodes();
return logLikelihood;
}This means any caller that subsequently calls state.store(sampleNr) (e.g. at the start of propagateState) is doing a redundant store. In the standard MCMC.doLoop() this happens after initialization and in the debug/correction paths, so it's not a performance issue in practice.
However, the implicit store(-1) is a surprising side effect for a method that looks like a pure calculation. It makes it harder to reason about state management when subclassing MCMC (e.g. for data tempering or other custom loops that need to call robustlyCalcPosterior mid-run).
Possible fix: document the side effect clearly, or restructure so the store is the caller's responsibility.
State.robustlyCalcPosterior()callsstore(-1)internally before recalculating the posterior:This means any caller that subsequently calls
state.store(sampleNr)(e.g. at the start ofpropagateState) is doing a redundant store. In the standardMCMC.doLoop()this happens after initialization and in the debug/correction paths, so it's not a performance issue in practice.However, the implicit
store(-1)is a surprising side effect for a method that looks like a pure calculation. It makes it harder to reason about state management when subclassing MCMC (e.g. for data tempering or other custom loops that need to callrobustlyCalcPosteriormid-run).Possible fix: document the side effect clearly, or restructure so the store is the caller's responsibility.