(De-)Coupling between operators and topologies

[bastinat0r]

Is your feature request related to a problem? Please describe.
I want to use PySwarms to benchmark several state of the art PSO-Algorithms (and some modifications for them). As I understood the current code-base implementing another variant that uses another velocity update (like the one used in SPSO2011) does not fit neatly into the current Class-dependencies, as the topologies do depend on the operators that are used. In my research I use, different operators with different topologies.

For reference the SPSO paper

Describe the solution you'd like
Decoupling of operators and topologies would suit the implementation of new algorithms, maybe that can help to gather new algorithms into PySwarms.

Describe alternatives you've considered
I'm not really sure what is the best way to achieve this. Maybe the operator can be passed as a named argument, thus the implementation is easier. I guess the cleanest approach is decoupling though.

Additional context
I want to test new algorithms/modifications regarding other metrics relevant to robotic applications of PSO (as part of my PhD topic). This coupling is really what keeps me from using pyswarms at the moment. There is however a real lack of (Single Objective) PSO frameworks out there so real heads up for the project!

[whzup]

Hello @bastinat0r and welcome to PySwarms! 😄 Thank you for your feature request. To me it sounds a bit like the BoundaryHandler we are currently developing #238 but instead of choosing how to handle the boundaries you would like to choose how the velocity and the new positions are calculated, right? I think we could consider this after release 0.4. We are currently very low on labour resources so it might take a while 😄. Although, I reckon that with some smart ideas this wouldn't even be that hard to implement 🤔.

[whzup]

@ljvmiranda921 I think this is actually pretty easy. Since the compute_position and compute_velocity methods of the topologies are actually not dependent on the class structure (they just call them from the operators module), we can just remove the method call in the optimizers and replace it with function calls directly with the functions from operators. I'm not entirely sure about how well it would work to pass compute_position and compute_velocity as parameters since we already have a huge parameter list for the general optimizer (but maybe another optimizer type could be implemented?).

[whzup]

As a sidenote, @ljvmiranda921, if you want to keep the compute_position and compute_velocity we could just pass it to the topology as an argument. Or even another idea would be to provide "hooks" before and after the computation of the values.

[ljvmiranda921]

Yeah, hmm, I agree with you @whzup , it seems that from an API standpoint it's quite a lot to generalize or decouple. I think your latter suggestion works, pass the compute_position and compute_velocity to the topologies...

But hmm, I also have this pull that it's actually ok to not decouple between compute position and compute velocity from the topologies? Like the toplogy guides how the computations happen, so it's fine if they're connected.

Let me know your thoughts! Wow, this has been a longstanding feature, but a good time to revisit!

[whzup]

Ok so just as an example, I worked on an integer optimizer for #400 (see there for the source). For that integer optimizer, one needs to have custom compute_position and compute_velocity functions. It was then that I realized that I have to rewrite an entire topology class just to implement a small change in the operators (if I wanted to stay true to our architecture). Of course, I could've just used the new functions in the custom optimizer but this just highlights that our current approach is not that modular.

There are 2 points for why I think we should decouple:

1. I'd actually argue, that the topology is only responsible for the neighbourhood relation of the particles and thus the computation of the best value in the neighbourhood and not for the more general computation of position and velocity. The methods for these two operations could actually be made static without problem as they do not use any information from the topology class.
2. The topologies do not guide all the computations but only for the gbest, position and velocity. The computations for pbest and current_cost are already decoupled from the topologies. In my mind it does not make sense why the position and velocity computation should be included in the topologies when the pbest and current_cost computation are not.

I think one definitively can work with custom operators at the moment but it feels unpolished, at least to me. As I see it, if we uncoupled them we would open up the ground for an even more general optimizer and give the backend a more sensible structure. I would then actually just remove the methods for position and velocity computation in the topologies and use the operators in the optimizer instead. This wouldn't change anything in the API of the current optimizers.

[whzup]

@ljvmiranda921 I have a branch prepared with the changes (all tests pass). If you approve of this change I'd be ready to put a PR.

[ljvmiranda921]

that the topology is only responsible for the neighbourhood relation of the particles and thus the computation of the best value in the neighbourhood and not for the more general computation of position and velocity.

Ok you've convinced me on this part. I do agree that our custom operators are still unpolished, and I haven't seen users try to use them or build their own optimization logic from scratch. I think moving forward you're right, it's good that we decouple them as much as possible so that users can either (1) arrange the parts as they see fit, and/or (2) just use our premade optimizers.

Just note that I'm wary of abstracting this too much, so let's be careful on that! Ok, I'm excited to see the PR! Might be able to review this over the weekend instead!

[ghost]

Is there any update on this? Would be super useful to have this decoupling implemented if possible, so that variations on the standard PSO (such as an FDR-PSO) can be created in PySwarms?

[ljvmiranda921]

Closing stale issues. Unfortunately, I think no one has the bandwidth to implement this feature. Please reopen this again if you think can contribute or still needed