TQDM status viewer comment

[apiszcz]

I wanted to mention another status option. I've been using TQDM in linking.py for a few months now with no issues, it is most help when supplied with the number of frames in the pred_link_df_iter) call. TQDM provides an estimate for time of completion.

The console view during tracking track: 1%|3 | 11/766 [00:00<00:54, 13.96it/s]C

from tqdm import tqdm

around line 615
def link_df_iter(features, search_range, memory=0,
            neighbor_strategy='KDTree', link_strategy='auto',
            predictor=None, adaptive_stop=None, adaptive_step=0.95,
            diagnostics=False, pos_columns=None,
            t_column=None, hash_size=None, box_size=None,
            verify_integrity=True, retain_index=False, number_of_frames=0):

around line 720
    for labeled_level, source_features, old_index in tqdm(zip(
            labeled_levels, features_forpost, index_iter),
            desc='track',total=number_of_frames):

[nkeim]

Thanks. I have been using tqdm on the earlier recommendation of @apiszcz and I think it is excellent. It is already straightforward to add tqdm to link_df_iter by wrapping the input iterator. Plus many users would want to choose the tqdm_notebook version instead. I think that if we are going to make tqdm an optional dependency, we should try to do it at the level of the trackpy-wide logging system as some sort of globally settable flag. If tqdm is installed, there are several parts of trackpy that would benefit from a nice progress bar.

I wish there was a way to avoid the number_of_frames kwarg. Obviously in many cases tqdm can successfully use len(), but not when the input is a homemade for loop. (This is a perfect use case for slicerator!) The necessity of the number_of_frames argument is the main argument against this proposal—it barely saves any work compared to typing tqdm().

Thoughts from anyone else?

On Aug 24, 2017, 4:01 AM -0700, apiszcz notifications@github.com, wrote:

I wanted to mention another status option. I've been using TQDM in linking.py for a few months now with no issues, it is most help when supplied with the number of frames in the pred_link_df_iter) call. TQDM provides an estimate for time of completion.

The console view during tracking track: 1%|3 | 11/766 [00:00<00:54, 13.96it/s]C

from tqdm import tqdm

around line 615 def link_df_iter(features, search_range, memory=0, neighbor_strategy='KDTree', link_strategy='auto', predictor=None, adaptive_stop=None, adaptive_step=0.95, diagnostics=False, pos_columns=None, t_column=None, hash_size=None, box_size=None, verify_integrity=True, retain_index=False, number_of_frames=0):

around line 720 for labeled_level, source_features, old_index in tqdm(zip( labeled_levels, features_forpost, index_iter), desc='track',total=number_of_frames):

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/soft-matter/trackpy/issues/449, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AC2NbZZzX04_KTq6WQ7p_VEO2e4lL28eks5sbVf7gaJpZM4PBOW-.

[apiszcz]

I am acquiring the frame count to pass in as number_of_frames

number_of_frames=df.frame.nunique()

For long running sessions it is really helpful to have some idea of end state time, seconds, minutes, hours, etc.

On Thu, Aug 24, 2017 at 1:08 PM, Nathan Keim notifications@github.com wrote:

Thanks. I have been using tqdm on the earlier recommendation of @apiscz and I think it is excellent. It is already straightforward to add tqdm to link_df_iter by wrapping the input iterator. Plus many users would want to choose the tqdm_notebook version instead. I think that if we are going to make tqdm an optional dependency, we should try to do it at the level of the trackpy-wide logging system as some sort of globally settable flag. If tqdm is installed, there are several parts of trackpy that would benefit from a nice progress bar.

I wish there was a way to avoid the number_of_frames kwarg. Obviously in many cases tqdm can successfully use len(), but not when the input is a homemade for loop. (This is a perfect use case for slicerator!) The necessity of the number_of_frames argument is the main argument against this proposal—it barely saves any work compared to typing tqdm().

Thoughts from anyone else?

On Aug 24, 2017, 4:01 AM -0700, apiszcz notifications@github.com, wrote:

I wanted to mention another status option. I've been using TQDM in linking.py for a few months now with no issues, it is most help when supplied with the number of frames in the pred_link_df_iter) call. TQDM provides an estimate for time of completion.

The console view during tracking track: 1%|3 | 11/766 [00:00<00:54, 13.96it/s]C

from tqdm import tqdm

around line 615 def link_df_iter(features, search_range, memory=0, neighbor_strategy='KDTree', link_strategy='auto', predictor=None, adaptive_stop=None, adaptive_step=0.95, diagnostics=False, pos_columns=None, t_column=None, hash_size=None, box_size=None, verify_integrity=True, retain_index=False, number_of_frames=0):

around line 720 for labeled_level, source_features, old_index in tqdm(zip( labeled_levels, features_forpost, index_iter), desc='track',total=number_of_frames):

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ soft-matter/trackpy/issues/449, or mute the threadhttps://github.com/ notifications/unsubscribe-auth/AC2NbZZzX04_KTq6WQ7p_ VEO2e4lL28eks5sbVf7gaJpZM4PBOW-.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/soft-matter/trackpy/issues/449#issuecomment-324697446, or mute the thread https://github.com/notifications/unsubscribe-auth/ABXVTZ7CkPNotEhTUeTTnjZZQ9NW1eAHks5sba4PgaJpZM4PBOW- .