Add backend module

[ljvmiranda921]

Reference: #111
Branch: Development

The idea for the backend module is that we can abstract away common PSO operations such
as generating swarms or updating velocities or positions. Once we have a module that does that,
we can replace our current implementations (GlobalBest, LocalBest) with the backend operations.

Ideally, this should provide a white-box approach for users who would like to build their own swarm algorithm. They don't need to rely on very clunky classes we provide. They just import the backend and use them in ways they wish.

Another advantage of this approach is that it gives us the ability to test various parts of the GlobalBest and LocalBest implementations. This is really helpful for us as well.

This might interest you, @SioKCronin . You can review my code if you want (or if you have time), but this is still WIP 😄

[ljvmiranda921]

I was wrong, we should bring back the option where velocity_clamp = None. I thought I can go around it by simply setting clamp = (0,1). The previous commit fixes that.

[ljvmiranda921]

I'll probably finish everything first before I request for review 👍 But you can comment whenever you feel

[ljvmiranda921]

TODO (This weekend 5/26)

• Update BinaryPSO and DiscretePSO with new backends (might be unruly so hopefully we can also fix Returning an empty subset as the best subset for feature selection #110 in the process). Where to do the editing: Swarm class
• Update Documentation (i.e., ReadTheDocs, some examples on how to use the backend, short example in creating your own evolutionary-loop [white-box approach) Make another PR for this

[ljvmiranda921]

Should we actually use topologies instead when computing for the best cost and position?

I'm thinking of generalizing the compute_gbest() and compute_gbest_neighborhood() methods in just a single Topology. The idea is that we have a compute_best_particle that changes its behavior depending on the topology present. This changes how best_pos and best_cost is computed and in turn affects the particle's velocity.

best_cost, best_pos = compute_best_particle(swarm, topology='star') # For GlobalBestPSO

Perhaps a rough draft of compute_best_particle() would be:

# compute_best_particle() example
# Perhaps we should define this into another file but automatically imported
# from __init__.py?

def compute_best_particle(swarm, topology):
    try:
       # A dictionary that maps keys into methods?
       # Then if the topology requires additional param, like k or p in `ring`,
       # It will just take it from the `options` attribute of the swarm
       best_cost, best_pos = topologies[topology](swarm)
    except KeyError:
        raise
    else:
        return (best_cost, best_pos)

# So the dictionary looks like this...

topologies = {
    'star' : star,
}

Hmmm, it really looks funky to me though

Or

from pyswarms.backend import Topology

my_topology = Topology('star')
cost, pos = my_topology.compute_best_particle(swarm)

Uhhh... but you still need to map these values though.

Another one

from pyswarms. backend.topologies import Star

my_toplogy = Star()
cost, pos = my_topology.compute_best_particle(swarm)

Uhhh... but this means we need to build a class for each topology. Aside from computing the best particle, what other methods should we actually associate to a Topology?

---

Any thoughts here, @SioKCronin