While writing the detailed documentation, I discovered a better way to write the looper based on a counter on the number of events that should have been executed. Thus, instead of documenting the algorithm as is, I documented the better algorithm, even tho the code doesn't actually implement this.
I believe this would be a better way to write the looper as opposed to the current design, which kind of works on the difference/deltas of the number of events that should have been executed. The reason it is better is that it would be easier to understand, easier to analyze, and possibly more correct for difficult-to-maintain rates. This rewrite should probably be done.
While writing the detailed documentation, I discovered a better way to write the looper based on a counter on the number of events that should have been executed. Thus, instead of documenting the algorithm as is, I documented the better algorithm, even tho the code doesn't actually implement this.
I believe this would be a better way to write the looper as opposed to the current design, which kind of works on the difference/deltas of the number of events that should have been executed. The reason it is better is that it would be easier to understand, easier to analyze, and possibly more correct for difficult-to-maintain rates. This rewrite should probably be done.