pyswarms: wrong implementation/definition of ftol_iter

Description

When ftol is used, for example 1e-10, pyswarm stops when swarm.best_cost is lower than ftol for ftol_iter times. However, the correct naming of ftol_iter should be stall_iter. This means that the search stops when best_cost isn’t improved after x iterations, or when it is below ftol. However, when I search for a solution, I need to stop the search when the best_cost isn’t improved after x iterations or when it is below ftol (must happen only once).

The current naming and implementation is confusing and doesn’t make sense. That’s why I thought I had to set ftol_iter=1 which caused stopping after the first iteration and having premature solution ([0.03840509 0.00329153] instead of [-9 -9]).

In this regard, the default value of ftol_iter should be big enough (at least 100) to avoid having premature solution. ftol_iter=1 is unusual and very small.

This is what I got with ftol=1e-10 and ftol_iter=100. As can be seen, it must stop after iteration 199.

196 = {float64} 1.543800321250907e-10
197 = {float64} 1.543800321250907e-10
198 = {float64} 1.543800321250907e-10
199 = {float64} 1.2788497031507338e-12   <-- stop here
200 = {float64} 1.2788497031507338e-12
201 = {float64} 1.2788497031507338e-12
202 = {float64} 1.2788497031507338e-12
203 = {float64} 1.2788497031507338e-12
204 = {float64} 1.2788497031507338e-12

Sample code A sample code is attached. The function to be optimized is a modified sphere function centered at [-9,-9]. The real cost is zero.

ftol_test.zip

Expected behavior As I said, I expect that the optimizer stops after ftol_iter iterations when there is no improvement (best_cost stalls) or it stops instantly when the best_cost is below ftol. With the current implementation, optimizer only stops after iteration around 300, after stalling for 100 iterations but with ftol around 2e-16, which is much lower than given ftol. However, it must stop somewhere around iterations 200.

Environment (please complete the following information):

PySwarms Version 1.3.0

Thank you. DATA-BOY

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 21 (16 by maintainers)

Most upvoted comments

@msat59 If you have already implemented the stall_iter let’s use that, otherwise I can work on a new PR.

@nishnash54, I have implemented it already. Just need to paste the code into BinaryPSO, and test it. I will submit it by this weekend.

msat59 on Feb 15, 2021

Hi all ,

So to round it up, the problem is on how we can incorporate @D4T4-80Y 's required functionality into Pyswarms, because as it turns out his/her expectation of ftol_iter is different. We now have three options:

Option A: implement stall_iter that is different from ftol_iter. While keeping the latter’s implementation the same.
Option B: implement stall_iter that is different from ftol_iter. Update the implementation of ftol_iter into something different, rename the current implementation of ftol_iter.
Option C: require early stopping, which might be a different use-case and implementation altogether.

I believe we’re leaning towards Option B? I’m ok renaming ftol_iter (cc: @nishnash54 ) If this is good then I think we can proceed

ljvmiranda921 on Feb 14, 2021

Hi @nishnash54.

The stall means no improvement in the best_cost no matter what its value is, which means it stays constant in two consecutive iterations . In other word, diff=0 which is always less than ftol.

The concept is taken from deep learning where we require the model to achieve the set threshold over the next few iteration to stop further training.

What you are referring to is called Early Stopping (mostly used in Neural Networks) and the main purpose is to avoid overfitting while training a model. So the algorithm stops training once the model performance stops improving on the validation dataset for the given number of iterations. THIS IS HOW ftol_iter WORKS AT THE MOMENT.

D4T4-80Y on Feb 14, 2021