awaelchli
commented
2 years ago It probably makes sense for some of these but how would you represent for example the val_batch_idx directly on the loop? The logic that is implemented there is taking the value from either one or the other loop, so it seems this type of branching will always be necessary in the progress bar.
carmocca
Proposed refactor
Move these:
https://github.com/PyTorchLightning/pytorch-lightning/blob/6490996b3974019a254f2750f5c01e6d38ff6a6e/pytorch_lightning/callbacks/progress/base.py#L80-L173
To their respective loops.
Deprecate the existing progress bar properties.
Have the progress bar use the new properties.
Motivation
These properties can be useful for other components, but since they are defined in the progress bar, it forces users to either copy the implementation or require that the progress bar is available
Pitch
We can also take advantage and rename them to reduce confusion. For example, even though they are suffixed with
_idx, they are not indices.If you enjoy Lightning, check out our other projects! ⚡
Metrics: Machine learning metrics for distributed, scalable PyTorch applications.
Lite: enables pure PyTorch users to scale their existing code on any kind of device while retaining full control over their own loops and optimization logic.
Flash: The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, fine-tuning, and solving problems with deep learning.
Bolts: Pretrained SOTA Deep Learning models, callbacks, and more for research and production with PyTorch Lightning and PyTorch.
Lightning Transformers: Flexible interface for high-performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.
cc @justusschock @awaelchli @rohitgr7 @kaushikb11 @carmocca @ananthsub @ninginthecloud