Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #24 (thanks also to @andrewlesak for the prototype) and some of my own projects have highlighted that it would be useful to be able to print multiple progress bars when the scan or loop is inside a vmap. Currently this will push all the updates to a single progress bar (as the scanned function is compiled once for the vmap, and so only one progress bar is initialised), showing false progress updates when using vmap.
My approach here has been to allow the user to inject an id for the progress bar, which is then carried through the loop or scan, which then allows updates to be routed to individual progress bars. For example with a scan
Here
BarId
is a simple class that contain the id of the progress bar and the carried value. The user needs to wrap theinit
of the scan in aBarId
and provide an integer id, and conversely unpack the results afterwards. Using a class like this is an easy way of detecting when a user has provided a bar-id.This approach means the original scan function can still be used without modification (you can just provide the carry without wrapping), and overall it has a fairly low impact on the overall API. I guess it adds some complication (mainly arising from needing to initialise the bars at runtime rather than compile time) requiring users to bundle up the scan arguments.
Welcome any thoughts on this API change!
*Note that some terminals don't support updating multiple bars (for example the PyCharm terminal) this is a known bug with TQDM