Mitigate overflow when calculating ETA

[csparker247]

Mitigates the overflow that occurs when max progress is very large.

See #77

[p-ranav]

Since the single_include is generated, can you make these changes to include/indicators/block_progress_bar.hpp and include/indicators/progress_spinner.hpp?

[csparker247]

Can do. Is the appropriate call for running the generator documented somewhere so I can make sure single include is updated the correct way as well?

[p-ranav]

Yes! Here: https://github.com/p-ranav/indicators#generating-single-header

[csparker247]

I looked right over it! Thanks!

[csparker247]

Unintended consequence of this change is that the time remaining now starts counting up after awhile:

Investigating.

[csparker247]

The counting up problem is due to integer truncation. For example, at step 51/100, 100/51 = 1.96 which truncates to 1 for all progress values > 50. This is of course not a problem in the original version because the division happens later.

After thinking about this more, there are three ways we can organize the order of operations here and I think they all have problems:

• (elapsed * max_prog) / prog: overflows eventually for large values of elapsed and quickly for large values of max_prog
• elapsed * (max_prog / prog): significant truncation error for normal values of max_prog
• (elapsed / prog) * max_prog: always 0 for prog > elapsed, which could pretty easily happen if progress is set manually, but probably only for non-default max_prog

It seems like the last option is the least bad, but I only have my use case to go on. An alternative that requires more work but is probably more stable is to keep a rolling average of the iteration rate and use that to project ETA. That appears to be what tqdm does.

EDIT: Or we just do all the math as floats.

[csparker247]

I ended up going for the floating point approach. The std::ceil could probably be removed, but it seemed better to overestimate by a nanosecond than to let it truncate.