Open jrapin opened 4 years ago
We would like to contribute and work on this issue. As we understood it, next to the EarlyStopping class in callbacks, you wanted to include further criteria such as relative improvement compared to the input or the time it has taken. Is the issue linked to #546 in order to determine wether FCMA is going to be used or not? Then we thought of maybe further including: maximum number of iteration (per CMA-ES run), whether Stagnation has occurred, the sigma ratio being bigger than a certain threshold or the condition number being bigger than a threshold.
For now the only stopping criterion is the budget, we should support others such as relative improvement or time
Related to #546
@jrapin Hello, a following question from @patrickld, which algorithm(s) we should work on to add an early stopping point? I believe algorithms have their own working styles, it is kind of hard to impose an early stopping point to all the algorithm in this library?
Hello, I am currently working on this issue with a group of people for an university proect. I studied the code and thought about a way to patch the repository in order to allow for a relative improvement early stopping criterion.
My idea is to use the base.Optimizer.current_bests
attribute and check whether, each time it is updated, the value of the loss function shows a relative decrease higher than the given threshold provided by the user when setting the callbacks.
I have already done the necessary modifications for my proposal, i hope you could take a look at it. I'll push the modifications soon. Thank you
For now the only stopping criterion is the budget, we should support others such as relative improvement or time
Related to #546