Tqdm bar

[itay-raveh]

#479

tqdm progress bars have been added to the generation iteration loop and the final output ind resotre loop in gp_optimiser and param_free_gp_optimiser

[codecov]

Codecov Report

Merging #481 (4527e6e) into master (47021d6) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #481      +/-   ##
==========================================
+ Coverage   76.98%   77.02%   +0.03%     
==========================================
  Files         132      132              
  Lines        9407     9419      +12     
==========================================
+ Hits         7242     7255      +13     
+ Misses       2165     2164       -1     

Impacted Files	Coverage Δ
fedot/core/optimisers/gp_comp/gp_optimiser.py	92.65% <100.00%> (+1.43%)	⬆️
...core/optimisers/gp_comp/param_free_gp_optimiser.py	79.62% <100.00%> (+1.42%)	⬆️
fedot/core/validation/compose/time_series.py	82.35% <0.00%> (-17.65%)	⬇️
fedot/core/validation/compose/tabular.py	85.71% <0.00%> (-14.29%)	⬇️
fedot/core/optimisers/gp_comp/gp_operators.py	95.61% <0.00%> (-0.88%)	⬇️
fedot/core/data/merge.py	94.37% <0.00%> (+1.25%)	⬆️
fedot/core/composer/advisor.py	96.96% <0.00%> (+6.06%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47021d6...4527e6e. Read the comment docs.

[nicl-nno]

I tested this solution, and it has an issue when the optimization timeout is set:

In this case, we have a near-infinite number of generations, since the evaluation time is limited by timeout, not the number of generations.

However, I am not sure that tqdm supports the time limit feature or there is the simple way to estimate the real number of generations. So, the improvement can be conducted in other PR.

P.S. For the next PR, i also have the idea to move the progress bar to OptimisationTimer to simplify the code.

[itay-raveh]

I tested this solution, and it has an issue when the optimization timeout is set:

In this case, we have a near-infinite number of generations, since the evaluation time is limited by timeout, not the number of generations.

However, I am not sure that tqdm supports the time limit feature or there is the simple way to estimate the real number of generations. So, the improvement can be conducted in other PR.

P.S. For the next PR, i also have the idea to move the progress bar to OptimisationTimer to simplify the code.

I noticed this, but as you say there is no simple way to estimate better than self.requirements.num_of_generations.

One solution is to create a different bar for when a timeout is the cap rather than the generations,
and either pick one of the two according to the parameters or let the user pick.

Would you like me to add those here or in a separate PR after this one has been closed?

[nicl-nno]

Would you like me to add those here or in a separate PR after this one has been closed?

Yes, it would be great if you do it.

[J3FALL]

@itay-raveh Thanks for the contribution!
It would be great if you continue to improve the project :)