Be able to display the instantaneous speed of the loop about tqdm

[casperdcl]

The gui version is a bit like windows 8/9 file transfer progress bars...

I've thought about this quite a bit, and think the best solution might be to take the average speed of the last 10 iterations...

[lrq3000]

I agree, this is something I have thought about before, but I'm not sure what would be the best estimate.

As @casperdcl said, a common method is to use a running average or a running median filter (which is equivalent to a low-pass filter), to avoid noisy iterations such as the 20% you mention.

Of course we can implement several different methods and let the user choose, but I think that if we're going to implement new methods, we might as well do some research about it as to find good methods to implement.

[lrq3000]

After a quick research, here are some results:

• Exponential weighted moving average: indeed it's very common in DSP. More infos here, here and here.
• Using not only a window over the number of iterations but also a window over the last x minutes.
• Improving ergonomics, eg, by dynamically updating the min_interval variable depending on how much time it will take and/or by making the prediction pessimistic (ie, predict more time than it will really take and speed up towards the end). Example here and research paper here.
• Discussions on why it is so hard (in fact impossible) to correctly predict remaining time in all cases: here, here, here and here.

And the necessary XKCD sketch:

So in the end, there's no perfect way to tackle this issue. Having a good time predictor requires to use machine learning algorithms on a sample dataset, which we cannot have in our case since we want the bar to be as general as possible. I think we should implement the "Exponential weighted moving average", which seems to be the go-to way of implementing reliable progress bars nowadays.

In addition, we could implement some kind of memorization of the iterations' durations. We could then make a pessimistic progress bar that would give more weights to the slowest iterations, and less to the fast iterations,

[lrq3000]

And of course, we can implement the algorithms the OP suggested, and leave the choice to the user.

[BertrandBordage]

@lrq3000 I agree with you, the exponential weighted moving average is probably the best solution for us (for the moment) for these reasons:

• it has no impact on the memory usage and an insignificant impact on CPU performance
• the smoothing factor can be changed by users, depending on the stability of the iteration speed
• it can act as a boolean to determine whether we want average speed or instantaneous speed: for average speed, use 0 as the smoothing factor, otherwise use 1

I suggest that we name that factor speed_smoothing, and that we set it to something like 0.7 by default.

This could eventually be improved later by using real statistics, but it would already be far better with that simple system, so I’m not sure it would worth developing it :)

[casperdcl]

K. Gonna implement ema then.

[BertrandBordage]

Thank you very much :D

[casperdcl]

Ok just writing tests for this. I tried to reinstall some coverage-related packages on my system a few days ago and now my coverage is broken.... Any Ideas how to fix? Been driving me nuts:

$ sudo -H pip show codecov coverage nose

---
Name: codecov
Version: 1.6.2
Location: /usr/local/lib/python2.7/dist-packages
Requires: coverage, requests
---
Name: coverage
Version: 3.7.1
Location: /usr/local/lib/python2.7/dist-packages
Requires: 
---
Name: nose
Version: 1.3.7
Location: /usr/local/lib/python2.7/dist-packages
Requires: 

$ nosetests --with-coverage --cover-package=tqdm -v tqdm/

tests_tqdm.test_format_interval ... ok
...
tests_version.test_version ... ok

Name            Stmts   Miss  Cover   Missing
---------------------------------------------
tqdm/__init__       6      6     0%   1-7
tqdm/_tqdm        177    177     0%   12-668
tqdm/_utils         6      6     0%   13-20
tqdm/_version       2      2     0%   2-5
---------------------------------------------
TOTAL             191    191     0%   
----------------------------------------------------------------------
Ran 17 tests in 0.006s

OK

[kmike]

@casperdcl likely tests are executed against installed tqdm, but coverage checks lines of tqdm in your folder. tox is great to prevent this kind of stuff :P

[casperdcl]

nvm. solved. (in case you're interested: sudo pip uninstall nose still left a bunch of *.so files under /usr/local/lib/python2.7/dist-packages/nose (not a full uninstall). Just had to clean out the folder and clean install. ;)

[lrq3000]

For reference in the future, two other algorithms:

• Simple Moving Median, equivalent to a low-pass filter or a median filter. The big advantage is that this algorithm is not susceptible to outliers (ie, big sudden and rare changes in the speed, but it adapts the rate quickly if the trend is regular).
• Moving average regression model, the killer weapon to model the trend using autocorrelative machine learning algorithm :p This is not so hard to implement, but it will surely take more computing time than the current algorithm we use. But surely this would be the most precise time estimation we can get.