Describe the bug When the ftol is used and the best cost is equal in two consecutive iteration, the search is stopped even if the cost is high.

To Reproduce options = {'c1': 0.5, 'c2': 0.3, 'w':0.9} optimizer = ps.single.GlobalBestPSO(n_particles=100, dimensions=2, options=options, ftol=1e-10) cost, pos = optimizer.optimize(fx.sphere, iters=1000, n_processes=None, verbose=True)

Output is something like this. Position: [0.06410654 0.02934344], Cost: 0.0049706854704889645

As can be seen, x1 and x2 are far from zero, the cost is relatively high, and it's much higher than 1e-10. The reason is that the algorithm couldn't find lower cost so the swarm.best_cost is equal to best_cost_yet_found. So the search is stopped even if the cost remains high.

Environment (please complete the following information):

• PySwarms Version 1.1.0

How to fix In optimizer code, an additional check should be performed to ignore if swarm.best_cost == best_cost_yet_found. After applying the fix, the output will be:

Position: [-8.05105641e-06 -6.63608458e-07], Cost: 6.525988549305629e-11

Description

Early unwanted stopping if ftol is used, no matter what threshold is set, because of no change in best_cost in two consecutive iterations.

Related Issue

• #397

• The logger was also improved to show the termination condition, and a bug in showing the progress bar was fixed too.

• Functions docstrings were also updated.

Motivation and Context

It avoids having an unwanted stop.

How Has This Been Tested?

All GlobalBestPSO, LocalBestPSO, and GeneralOptimizerPSO were tested for Sphere(), with following criteria:

• n_particles=50, dimensions=2, iters=300
• without ftol («iters=300» reached)
• ftol=1e-60 («iters=300» reached)
• ftol=1e-3 («ftol=0.001» reached)
• ftol=1e-10, ftol_iter=5 («ftol_iter=5» reached)
• ftol=1e-60, ftol_iter=50 («iters=300» reached)

Screenshots (if appropriate):

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [x] All new and existing tests passed.

After releasing v0.4.0, it seems that we already had some API changes that were not reflected in the notebook. What you need to do is just rerun all the notebooks in this link and update the code as necessary to account for API changes :+1:

Thanks to @SioKCronin , we're now able to implement hyperparameter search tools such as GridSearch and RandomSearch . These are awesome implementations, but we can maximize its robustness by adding an assertions() method in our classes. Would you like to try?

What you'll do

Simply put, you will just add an assertions() method in the SearchBase class. This should contain various checks when instantiating any class that inherits from it. You can check the docstrings for each class and create a proper method call for it.

If you want to check previous implementations, see the SwarmBase.assertions method, and check how it is being implemented in GlobalBestPSO (it is not called explicitly because it just inherits from the base) or in LocalBestPSO (additional lines of code were added after calling the super() because of extra attributes).

Go the extra mile?

If you want to go the extra mile, you can add tests to check for edge cases and see if your assertions are working when passed with an invalid input (maybe an invalid type, out-of-bounds, etc.). For this, you just need to add an Instantiation class in the test.utils.search.test_gridsearch and test.utils.search.test_randomsearch modules.

Again, if you want a template, you can check the Instantiation classes in test.optimizers.test_global_best and others. Notice how we try to feed the class with invalid arguments/edge cases and have the unit test capture them. It's a very fun activity!

If you wish to take this on, then feel free to drop a comment here! I'd be glad to help you!

Update: 9/17/2017

Follow the instructions in this quick-start guide to get you started!

Commit Guidelines

I'd appreciate if we lessen the number of commits per issue to 1-2. Of course you can commit often, but before merging, I would ask you to rebase them depending on the changes you've done. A commit format that we follow is shown below:

Short and sweet imperative title  (#27)

Description of the commit. The commit title should be short
and concise, and must be in imperative form. It could be as
simple as `Add tests for optimizer` or `Implement foo`. It describes
the "what" of the commit. You must also reference the issue, if any,
in the title. Here, in the description, we explain the
"why" of the commit. This is more or less free-for-all. So you can
describe as detailed as possible, in whatever tense/form you like.

Author: <your-github-username>
Email: <your-email>

Description

This PR implements the new BoundaryHandler and VelocityHandler classes that deal with the issue of particles that don't move in optimisations with boundary conditions. This is achieved by using different strategies that have been described in Hel10 (P. 28). These strategies include:

• Nearest bound: Reset particle to the nearest boundary
• Random: Reset the particle to a random position within the bounds
• Shrink: Shrink the velocity such that the particle touches the boundary instead of surpassing it
• Intermediate: Reset the particle to a value between its former location and the bound
• Resample: Calculate new velocities until the next particle position is within the bounds
• Periodic: Tile the space with the same search space over and over

There is one more:

• Reflective: Mirror the position of the particle at the surpassed boundary

I won't include the last one in this PR as it is probably provided by @jolayfield. After they've made their PR I'm going to embed their code in the BoundaryHandler class. The strategies for the VelocityHandler include:

• Unmodified: The velocity remains without modification
• Adjust: The velocity is adjusted to be exactly the distance vector between the previous and the current position.
• Invert: The velocity is inverted.
• Zero: The velocities of particles that go out-of-bounds are set to zero.

Related Issue

Resolves: #237 See also: #150, #234

Motivation and Context

In #234 we encountered a weird phenomenon when optimizing with boundary conditions. A lot of particles stopped moving while the optimization was still running. This is caused by the waiving of updating the position in the compute_position() function when it leaves the boundaries. To fix this issue we introduce a new class called BoundaryHandler as well as a VelocityHandler which are going to reposition the particle instead of not updating it.

How Has This Been Tested?

Types of changes

• [ ] Bug fix (a non-breaking change which fixes an issue)
• [X] New feature (a non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [X] My code follows the code style of this project.
• [X] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [X] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests pass.

TODO:

• [x] Add BoundaryHandler
• [ ] Write tests for the BoundaryHandler strategies
• [x] Integrate the BoundaryHandler into the operators
• [x] Add VelocityHandler
• [ ] Write tests for the VelocityHandler strategies
• [x] Integrate the VelocityHandler into the operators
• [ ] Clean up documentation
• [x] Add functions for the strategies in LaTeX
• [ ] Check doc build for any LaTeX errors
• [ ] Clean up PR

Is your feature request related to a problem? Please describe. I know I have an expensive function to evaluate, I am doing a simulation based optimization of a hyper parameter space. I am planning to use HPC environment because of this. Can particles be evaluated in parallel? Synchronously or even asynchronously? I thought an approach similar to this would be interesting (let me know if article is inaccessible).

Describe the solution you'd like A switch to enable threads for particle evaluations. In particular, I am fine with firing off os.system() commands and waiting for return.

Describe alternatives you've considered I supposed I could write a sub-script that executes the swarm in parallel, evaluates the target function for each particle, and returns those values to the optimizer. This wouldn't allow for async optimization. Also, I could also try to write another optimizer, one that takes an option for the number of parallel particles.

What is the best way to go here? Still digging into this API currently.

Goal

PSO can be utilized in a wide variety of fields. To broaden our collection of tutorials, we'd like to have another example where we analyse a simple circuit with PSO. For some inspiration, you can visit the example section. I propose that, for the beginning, we start by analysing the circuit shown below. It has a resistor and a diode. The end-goal is to have a nice Jupyter notebook that goes through the whole process of writing this optimization program.

Method

As there are many models for diodes, let us use a more realistic one (a simplified Shockley equation) for this tutorial:

where:

• : diode current
• : reverse bias saturation current
• : diode voltage
• : thermal voltage (use 25.3 mV in this tutorial)

to use it in the tutorial I'd recommend to solve for :

Using the Kirchhoff voltage law we get this:

where denotes the voltage over the resistor. We can restructure it to be our cost function (optimally it is 0) for the optimization:

The absolute value is necessary because we don't want to obtain negative currents. If we write this more verbosely we see that the current is the parameter we want to optimize:

These are some sample values for the other parameters:

• : 10 V
• : 9.4 pA
• : 100 Ohm

Of course, if you know an alternative way to solve this or you have any questions about the issue don't hesitate to write a comment! I'm looking forward to seeing a first-timer writing this Jupyter notebook! 💯

Notes

Please work on the development branch. You can find a good StackOverflow question about forking here. For a more advanced beginner guide to the GitHub workflow, there is this cheatsheet available. It is quite detailed and gives a simple overview.

Tasklist (Deadline: August 10, 2018)

• [x] Run black and flake8 for a clean format (drop)
• [x] Tests and minor changes for topologies (c/o @whzup )
• [x] Make a PyPI friendly README by following this link
• [x] Boundary conditions #150 (c/o @jolayfield) Moved to v.0.4.0 or on dev branch
• [x] Resolve issue with PyYaml, you can find a related issue in yaml/pyyaml#207
• [x] Update README (update authors and maintainers)
• [x] Merge all dependency updates in #162, #166, #173, and #178
• [x] Resolve all merge conflicts
• [x] Update HISTORY.rst
• [x] Write Release Notes
• [x] Bump version and update setup.py
• [x] Release: merge to master, make a Release, and upload to PyPI

Please write the changelog below for our release notes. It would be nice to follow this link.

Release v.0.3.0

We're proud to present the release of PySwarms version 0.3.0! Coinciding with this, we would like to welcome Aaron Moser (@whzup) as one of the project's maintainers! v.0.3.0 includes new topologies, a static option to configure a particle's neighbor/s, and a revamped plotters module. We would like to thank our contributors for helping us with this release.

Release notes

• NEW: More basic particle topologies in the pyswarms.backend module - #142, #151, #155, #177
• NEW: Ability to make topologies static or dynamic - #164
• NEW: A GeneralOptimizerPSO class. The GeneralOptimizerPSO class has an additional attribute for the topology used in the optimization - #151
• NEW: A plotters module for swarm visualization. The environments module is now deprecated - #135, #172
• FIX: Bugfix for optimizations not returning the best cost - #176
• FIX: Bugfix for setup.py not running on Windows - #175
• IMPROVED: Objective functions can now be parametrized. Helpful for your custom-objective functions - #144. Thanks, @bradahoward!
• IMPROVED: New single-objective functions - #168. Awesome work, @jayspeidell!

New Topologies and the GeneralOptimizerPSO Class

New topologies were added to improve the ability to customize how a swarm behaves during optimization. In addition, a GeneralOptimizerPSO class was added to enable switching-out various topologies. Check out the description below!

New Topology classes and the static attribute

The newly added topologies expand on the existing ones (Star and Ring topology) and increase the built-in variety of possibilities for users that want to build their custom swarm implementation from the pyswarms.backend module. The new topologies include: - Pyramid topology: Computes the neighbours using a Delaunay triangulation of the particles. - Random topology: Computes the neighbours randomly, but systematically. - VonNeumann topology: Computes the neighbours using a Von Neumann topology (inherited from the Ring topology) With these new topologies, the ability to change the behaviour of the topologies was added in form of a static argument that is passed when initializing a Topology class. The static parameter is a boolean that decides whether the neighbours in the topologies are computed every iteration (static=False) or only in the first one (static=True). It is passed as a parameter at the initialization of the topology and is False by default. Additionally, the LocalBestPSO now also takes a static parameter to pass this information to its Ring topology. For an example see below.

The GeneralOptimizerPSO class

The new topologies can also be easily used in the new GeneralOptimizerPSO class which extends the collection of optimizers. In addition to the parameters used in the GlobalBestPSO and LocalBestPSO classes, the GeneralOptimizerPSO uses a topology argument. This argument passes a Topology class to the GeneralOptimizerPSO.

from pyswarms.single import GeneralOptimizer
from pyswarms.backend.topology import Random

options = {"w": 1, "c1": 0.4, "c2": 0.5, "k": 3}
topology = Random(static=True)
optimizer = GeneralOptimizerPSO(n_particles=20, dimensions=4, options=options, bounds=bounds, topology=topology)

The plotters module

The environments module is now deprecated. Instead, we have a plotters module that takes a property of the optimizer and plots it with minimal effort. The whole module is built on top of matplotlib.

 import pyswarms as ps
 from pyswarms.utils.functions import single_obj as fx
 from pyswarms.utils.plotters import plot_cost_history

 # Set-up optimizer
 options = {'c1':0.5, 'c2':0.3, 'w':0.9}
 optimizer = ps.single.GlobalBestPSO(n_particles=50, dimensions=2, options=options)
 optimizer.optimize(fx.sphere_func, iters=100)

 # Plot the cost
 plot_cost_history(optimizer.cost_history)
 plt.show()

We can also plot the animation...

from pyswarms.utils.plotters.formatters import Mesher
from pyswarms.utils.plotters.formatters import Designer
from pyswarms.utils.plotters import plot_contour, plot_surface

# Plot the sphere function's mesh for better plots
m = Mesher(func=fx.sphere_func)

# Adjust figure limits
d = Designer(limits=[(-1,1), (-1,1), (-0.1,1)],
             label=['x-axis', 'y-axis', 'z-axis'])

In 2D,

plot_contour(pos_history=optimizer.pos_history, mesher=m, mark=(0,0))

Or in 3D!

pos_history_3d = m.compute_history_3d(optimizer.pos_history) # preprocessing
animation3d = plot_surface(pos_history=pos_history_3d,
                           mesher=m, designer=d,
                           mark=(0,0,0))    

Sir, I'm having problems with the out of bounds error. '5309' is the first element in my y. Here is the complete traceback:

IndexError                                Traceback (most recent call last)
<ipython-input-66-107cafabd9c0> in <module>()
     76 
     77 # Perform optimization
---> 78 cost, pos = optimizer.optimize(f, print_step=100, iters=1000, verbose=3)
     79 
     80 def predict(X_train, pos):

~\Anaconda3\envs\tensorflow\lib\site-packages\pyswarms\single\global_best.py in optimize(self, objective_func, iters, print_step, verbose)
    131         for i in xrange(iters):
    132             # Compute cost for current position and personal best
--> 133             current_cost = objective_func(self.pos)
    134             pbest_cost = objective_func(self.personal_best_pos)
    135 

<ipython-input-66-107cafabd9c0> in f(X_train)
     65 def f(X_train):
     66     n_particles = 100
---> 67     j = [forward_prop(X_train[i]) for i in range(n_particles)]
     68     return np.array(j)
     69 

<ipython-input-66-107cafabd9c0> in <listcomp>(.0)
     65 def f(X_train):
     66     n_particles = 100
---> 67     j = [forward_prop(X_train[i]) for i in range(n_particles)]
     68     return np.array(j)
     69 

<ipython-input-66-107cafabd9c0> in forward_prop(params)
     59     # Compute for the negative log likelihood
     60     N = 84 # Number of samples
---> 61     correct_logprobs = -np.log(probs[range(N), Y_train])
     62     loss = np.sum(correct_logprobs) / N
     63     return loss

IndexError: index 5309 is out of bounds for axis 1 with size 1

Describe the bug When running optimize in loop I get the growth of memory consumptions without any limits. If I specify the n_processes parameter the growth is even faster, but the issue persists even without this parameter.

To Reproduce Steps to reproduce the behavior:

import pyswarms as ps
from pyswarms.utils.functions import single_obj as fx

options = {'c1': 0.5, 'c2': 0.3, 'w': 0.9}
# Call instance of PSO
optimizer = ps.single.GlobalBestPSO(n_particles=20, dimensions=24, options=options)
while True:
    best_cost, best_pos = optimizer.optimize(fx.sphere, iters=50, n_processes=4)

Expected behavior No excessive memory consumption.

Environment (please complete the following information):

• OS: Linux
• Version Ubuntu 18.04
• PySwarms Version 1.1.0
• Python Version 3.6.8

Additional context Running in loop is important, because I may need to run it repetitively, when e.g. target of optimization changes and I need to get the new optimization results.

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

Description

Hi all,

I've just started using pyswarms and am stuck on defining a discrete design space when using the pyswarms.discrete.binary module.

I have got it running when using the ps.single.GlobalBestPSO module but I want to have points from 0 to 90 at 0.5 increments for my candidate solutions for each of my design variables (2 dimensional).

Any help would be much appreciated.

Cheers, Aidan

I believe the package cannot handle a few complex-conditioned functions. This is an example.

The function defined in the tutorial for "Basic Optimization with Arguments" is a simple non-conditional function.

Imagine we change such function to a more complex one which has a few IFs and we request more than one particle (n_particles = 10).

Because the input variables are passed to function as numpy arrays, the package fails to do such comparisons. Because it compares full arrays of numpy, for instance x[10:0]>x[10:1] and it correctly cannot handle these comparisons.

This is the error it reports and it means it is comparing arrays not members of arrays and the output is booleans regarding the whole array not its members.

ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Is there any way to use this package for more complex functions?

This is a minimum working example code which produces such a function and in case it is important, I am on a windows system with a python 3.10+.

# import modules
import numpy as np

# create a parameterized version of the classic Rosenbrock unconstrained optimzation function
def rosenbrock_with_args(x, a, b, c=0):

    tmp0 = x[:, 0]
    tmp1 = x[:, 1]

    if tmp0 > tmp1:
        f = (a - tmp0) ** 2 + b * (tmp1 - tmp0 ** 2) ** 2 + c
    else:
        f = 0
    return f

from pyswarms.single.global_best import GlobalBestPSO

# instatiate the optimizer
x_max = 10 * np.ones(2)
x_min = -1 * x_max
bounds = (x_min, x_max)
options = {'c1': 0.5, 'c2': 0.3, 'w': 0.9}
optimizer = GlobalBestPSO(n_particles=10, dimensions=2, options=options, bounds=bounds)

# now run the optimization, pass a=1 and b=100 as a tuple assigned to args

cost, pos = optimizer.optimize(rosenbrock_with_args, 1000, a=1, b=100, c=0)

Hello, thanks for that job. i encounter an issue in usage: I prepare my own optimization loops and an issu eoccurs in gbest computing the output value is not the minimum value.

i modify and try directly using GlobalBestPSO or GeneralOptimizerPSO and both return me that error at the end of first iterations run : "mask_cost = swarm.current_cost < swarm.pbest_cost TypeError: '>' not supported between instances of 'float' and 'NoneType' "

resulting code stop i guess it look like at first run the swarm.pbest_cost not been initialize

i am on Win 10 Python 3.9.6 Pywswarms 1.3.0

I don't think this needs much explanation, but if user could pass verbose and n_processes to the hyperparamter tuning algorithms like RandomSearch or GridSearch along with other parameters (e.g., bounds) that would be great. Great job putting this together.

Description

This PR implements an option to provide the swarm position, velocity and global best (or any particle) to the optimizer. This was performed by adding the following optional arguments to the optimizer class:

• init_vel
• init_best

The arguments were added to GlobalBestPSO, GeneralOptimizerPSO and LocalBestPSO as well as to the abstract base classes SwarmOptimizer and DiscreteSwarmOptimizer.

The optimizer can now be called as follows:

# Call instance of PSO 
optimizer = pyswarms.single.GlobalBestPSO(
                    n_particles=100, dimensions=dim, options=options, bounds=bounds, 
                    init_pos=init_pos,init_vel=init_vel,init_best=init_best)

Related Issue

Motivation and Context

The current implementation does not allow to properly resume a previous optimization process. This PR makes it possible while maintaining full compatibility with previous versions.

How Has This Been Tested?

This has been tested in a limited manner so far. Only using GlobalBestPSO on Ubuntu 18.04, python 3.6.

Screenshots (if appropriate):

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly (modified docstrings in the code).
• [ ] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.