Pytorch-lightning: slim down progress bar default printing

[CarloLucibello]

🚀 Feature

The progress bar is cluttered, too many prints by default. Let's remove some of them.

Pitch

Hi guys,
I feel the progress bar contains some uninformative prints and leaves little space for user customization.

This is the progress bar print before validation, with empty tqdm_dict (so no user addition to the progress bar metrics):

Epoch 1:  39%|███▉      | 343/875 [00:07<00:10, 48.46batch/s, batch_nb=342, gpu=0, loss=0.408, v_nb=18]  

This is after a validation step where I add to the tqdm_dict validation accuracy and loss:

Epoch 2:  20%|█████████████████▏                                                                      | 171/875 [00:03<00:11, 58.99batch/s, batch_nb=170, gpu=0, loss=0.267, v_nb=21, val_acc=91.8, val_loss=0.278]

To avoid more clutter and make some room for user-defined metrics, I propose to remove the following outputs from the progress bar:

• batch_nb: this is redundant, essentially the same number is printed on the left
• loss: this is something always computed in the training step. If the user wants to show it, he just adds it to the tqdm_dict
• gpu: this info is useless in single-gpu setting, and likely also in multi-gpu ones.
• v_nb: This is the experiment version number, which is very convenient to know. Since it stays the same during the whole experiment, we could just print it by default before the training starts.

Also, I propose to rename "batch/s" to tqdm default "it/s" to save a few extra characters.

Pinging @tullie @Borda since this discussion almost started in #531 .

Best,
C

[williamFalcon]

great suggestion. let's make all the changes you suggested except:

• keep loss
• keep v_nb (but rename to v_num)

Submit a PR when ready!

[tullie]

Yeah great suggestion. This is something i've been thinking about as my tqdm dictionaries tend to be pretty big.

@williamFalcon, what's your reasoning for keeping loss? One issue I have with the default loss is that it only displays with 3 precision numbers so I have to put it in the tqdm anyway. Of course, that could be fixed in other ways but this seems like a decent solution. I'd suggest keeping loss as a default only when the tqdm dictionary isn't supplied.

I'd like to hear your justification on keeping v_nb too. It does seem wasteful considering it's constant throughout training.

[CarloLucibello]

I would be as lean as possible with the defaults because it is quite easy for the user to add stuff, while it is impossible to remove the defaults.

I'd suggest keeping loss as a default only when the tqdm dictionary isn't supplied.

I like this proposal: with a "default" tqdm_dict that we can override we achieve both convenience and full flexibility

[williamFalcon]

@CarloLucibello @tullie want to submit a PR?