Applying large bounds results in a non-optimal solution and a Value Error

Describe the bug If I try to apply a large upper bound to my problem, I no longer get the same optimal solution I was getting. I would think that the bounds would only come into play if the particle reaches the bound and therefore should not affect the solution to much.

Also, if the bounds are large enough PySwarms returns the error “ValueError: operands could not be broadcast together with shapes (0,) (10,2)”

Here are some examples, using the basic example provided. This first example works fine:

# Create bounds 
max_bound = 10e2 * np.ones(2)
min_bound = -10e2 * np.ones(2)
bounds = (min_bound, max_bound)

# Call instance of PSO
optimizer = ps.single.GlobalBestPSO(n_particles=10, dimensions=2, options=options, bounds=bounds)

# Perform optimization
cost, pos = optimizer.optimize(fx.sphere_func, print_step=100, iters=1000, verbose=3)

This next one gives a result that far from the near zero optimum.

# Create bounds
max_bound = 10e20 * np.ones(2)
min_bound = -10e2 * np.ones(2)
bounds = (min_bound, max_bound)

# Call instance of PSO
optimizer = ps.single.GlobalBestPSO(n_particles=10, dimensions=2, options=options, bounds=bounds)

# Perform optimization
cost, pos = optimizer.optimize(fx.sphere_func, print_step=100, iters=1000, verbose=3)

And this last one returns the error "ValueError: operands could not be broadcast together with shapes (0,) (10,2) "

# Create bounds# Creat 
max_bound = 10e200 * np.ones(2)
min_bound = -10e2 * np.ones(2)
bounds = (min_bound, max_bound)

# Call instance of PSO
optimizer = ps.single.GlobalBestPSO(n_particles=10, dimensions=2, options=options, bounds=bounds)

# Perform optimization
cost, pos = optimizer.optimize(fx.sphere_func, print_step=100, iters=1000, verbose=3)

Maybe I am misunderstanding what is meant by the term bounds, but I don’t think it should behave like this. Also, a nice feature would be to allow the user to set an infinite upper bound say, (0,inf) in the case that they only want to consider positive numbers.

[whzup]

Thanks for reporting this @tex-downey. I took a look at the problems and I think the first one is the same that is already addressed in #150.

Problem: Far from the optimum First of all, you use 10 particles these 10 particles are then uniformly distributed over the whole space. Let’s say we take the bounds in the second example then we’d have a space of 10e22 x 10e22 square units, this results in huge distances between the particles and in insanely high “velocities”. This might cause the particles to “fly” into the bounds where they don’t move a lot.

This next one gives a result that far from the near zero optimum.

The optimization results are actually pretty “close” to the optimum in comparison to the bounds. Even if you would get a result around 10e5 you’d still be orders of magnitude below the boundary conditions. PSO scales with the particle space because you calculate the velocity based on the distance between the points which in this example is massive.

Also, you have to increase the number of iterations in such a vast space (just compare the results of, for example, bounds of 10 and -10 and bounds of 100 and -100 with 100 iterations each. The one with the bounds of 10 is orders of magnitude below the result of the one with bounds of 100).

@ljvmiranda921 maybe we should note the fact that PSO scales with the search space somewhere in the documentation so people don’t get confused by these huge numbers they get out when they use large boundaries?

Problem: ValueError

And this last one returns the error "ValueError: operands could not be broadcast together with shapes (0,) (10,2) "

This is actually a result of an OverflowError in the sphere_func. The sphere function is implemented like so:

j = (x**2.0).sum(axis=1)

It throws the following error:

RuntimeWarning: overflow encountered in square

If you square a number near 10e200 you get around 10e400. The float maximum in Python is (in my Python distribution):

>>> sys.float_info.max
1.7976931348623157e+308
>>> 10e200**2
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    10e200**2
OverflowError: (34, 'Result too large')

Consequently, the squared number is way above the limit of Python itself.

@ljvmiranda921 we should include this one in the documentation as well. Or can we fix this with anything? I found this standard library module which supports alterable precision.

[whzup]

It might be helpful to see the whole error message with the reference to the line of code which threw the Value Error 😄.