seantronsen
commented
7 months ago So far based on some other topics that I've been reading up on, I know that joblib does have support for memoization and could be used here. We could provide this as an option, disabled by default.
However, there are some issues with this idea:
- One of the ideologies I'd like to abide by is ensuring a relatively small number of dependencies are associated with the project. Fewer moving parts usually results in a system that's easier to debug and breaks less often.
- Including this feature would pose a detriment to analyzing more stochastic processes. This past weekend, I worked on a project which required coding up particle filters which employ Bayesian probabilities as an inference mechanism. Even though 'random' algorithms rely on not-so-random number generators, the process remains stochastic enough that memoization of callback inputs would hide everything that's really going on in the background. Imagine you have an animation or play through a sequence of frames and the probabilistic process runs on those frames. Memoization by definition wouldn't let you observe different behaviors with each loop of the animation. Instead, you'd see something that's already been seen before.
- How would this work with the current animation structure which remains untethered to any callback interface. That is, there is no way to know when the animation will repeat since we use time ticks and not frame numbers (modulo arithmetic is instead used for looping inside the callback). Introducing this feature would introduce coupling that doesn't need to exist in the first place.
Yeah, this isn't a big deal and it should ultimately be the responsibility of library users to know details like this, if memoization was implemented. Still, like some other possible features, it's just another detail that can be forgotten and lead to hours of frustration. Plus, there isn't anything stopping users from adding memoization to their own callbacks using the libraries they prefer.
Closing this feature. If anyone has a problem with this in the future, the issue can be re-opened.
If a callback function receives a set of arguments that was seen in the last N executions (N is programmatically adjustable), we should just return a cached result.
This would be particularly useful for the mandatory callback interface proposed in https://github.com/seantronsen/qtviewer/issues/19 as it would relate to both static and semi-static (views with a small set of known displays) views.