More Customisation in utils.ProgBar

[stellarpower]

The new progress bar in Keras v3 is rather pretty! But the colour and character for the ticks are currently hardcoded. I've modified mine to add a different colour for inference and training, so that I can see more clearly what's happening in the terminal. I also like to add the epoch at the end, as the output from training my model has extra print statements and so is usually very noisy.

Hardcoding is bad, so it would be good to make the character, the colours, etc. arguments to the ctor that we can change. Admittedly there would be several steps to go through to change this easily from high-level code where we define our model, but it'd be a good start.

Alternatively, using a/moving this class to a dedicated package for printing progress bars might make sense (DRY), but I assume there may be a reason it's hand-rolled in the sources.

Thanks

[SuryanarayanaY]

Hi @stellarpower ,

This is more like user experience related.IMO this is hardcoded to just keep it simple.

If you want to propose some user controls please feel free to raise a PR. Keras team may review and take appropriate action. Thanks!

[fchollet]

We could make the colors customizable via constructor arguments to Progbar, but that customization wouldn't be available directly via fit() (You'd have to pass your own progress bar callback).

[briango28]

We could make the colors customizable via constructor arguments to Progbar, but that customization wouldn't be available directly via fit() (You'd have to pass your own progress bar callback).

Squeezing all those extra arguments into fit() would be rather unwieldy I think. I'm of the opinion that anybody interested in a custom Progbar would (or at least should) be perfectly happy with passing in an explicit Progbar instance.

[stellarpower]

Squeezing all those extra arguments into fit() would be rather unwieldy

Yeah, I'd totally agree with that, squashing in loads of arguments over and over is something I really don't like when working with Python code - I wasn't aware I could pass my own to fit.

For now what I have done is changed the callback to set the colour depending on whether we're training, validating, or inferring. For my model, I need to plot my data to make any sense of it, so I originally wanted this feature for myself because I could rapidly get confused when scrolling back in the terminal, as with weights and biases thrown in and checks to see if the model has given up on life and just plotted a straight line I have quite a lot of callbacks.

But I think it's always good to make things modular and buy not build. Is there a particular motivation for including a custom one within Keras, rather than using an existing package (e.g. tqdm is one I have seen come up)? Or just to avoid extra dependencies? Googling, I see a number of torch users lament about not having a similar bar before Keras 3, so I would see a motivation for merging parts of this into a more general package and hen just using it within Keras.

Also, tangential, but on the topic of the progress bar, I see the callbacks are ordered in such a way that the progress bar is at the end of the list. This messes up my terminal when another callback prints something at the end of the epoch, so I changed it such that the progress bar update is always the first in the list. Is there also a reason it ought to be at the end I haven't thought of? It makes conceptual sense in that the epoch isn't complete until all of the callbacks have run, but I wonder how many others have a similar situation to mine, in which the console gets garbled if they need to log anything during their own callbacks.

Cheers

[fchollet]

The reason for having the progress bar at the end is that it prints metrics logs, and metrics can be added by other callbacks. If it were the first callback, it might ignore a bunch of data inserted into the logs dict by other callbacks.

If you pass your own custom progress bar, you can have callbacks in any order you want.

[stellarpower]

Right, gotcha. Are these the ones on the right of the bar? I get something like a dictionary printed below the bar each epoch, but I think it may be a callback adding that. Maybe I should use a more sophisticated logging setup.