Menu
▾
▴
#13 Redundancy in BoundaryConstraint classes...
There are two different implementations of the boundary constraint handling mechanisms for pso.
One of them defines an enforce(...) interface and can be found in the pso.iterationstrategies package while the other defines a constrainLower(...) and constrainUpper(...) interafce and can be found in pso.positionupdatestrategies.boundaryconstraintstrategies...
The former is built into the iteration strategy and provides a more "elegant" solution (this is my opinion). I, thus, suggest that the implementation of the latter be merged into it...
Regards,
Arnith
Some clarification:
The pso.iterationstrategies.BoundaryConstraint interface can be used for any Entity and not just a Particle. It should therefore be moved to a more generic package.
The pso.positionupdatestrategies.boundaryconstraintstrategies.BoundaryConstraintStrategy interface is used during the position update phase of Particles. It is therefore PSO specific, since other Entities do not have a position update phase.
It is true that you can achieve the same effect with the pso.iterationstrategies.PerElementReinitialisation and pso.positionupdatestrategies.boundaryconstraintstrategies.RandomBoundaryConstraintStrategy.
The difference between the classes in the separate packages is that pso.iterationstrategies only occurs after the Entity has already moved out of the search space which results in a post-constraint, whereas the pso.positionupdatestrategies.boundaryconstraintstrategies prevents the Particle from moving out of the search space which results in a pre-constraint.
I can understand the concern with the pre / post constraint argument to a degree, however, this is not a valid reason to keep the structure the way it is.
The current process (for PSO) is as follows (outlined as post-constraint by Theuns):
1. Update the velocity
2. Update the position
3. Enforce boundary constraints
The other strategy is as follows:
1. Update the velocity
2. Update the position and check the constraint violations for each dimension
This raises a few interesting observations:
1. The boundaries are only manipulated on / near the position updates
2. The current pre strategy can only be done on the standard position update equation (which is a big issue imho - we should be able to apply these strategies to ALL position updates)
3. The pre / post argument is kinda a moot point as the location of the operation is effectively the same for both strategies. Doing the operation during / after is simply a shift in the logic, much like the Synchronous and Asynchronous iteration strategies in the PSO.
The OP made an interesting comment and I tend to agree. Can anyone give a concrete clarification on why this change should not happen?
2. A small change will allow the BoundedPositionUpdateStrategy to wrap/decorate any other PositionUpdateStrategy.
3. There are many other PositionUpdateStrategies (not just Random) that can only be achieved as pre-updates. Post boundary constraints will not be possible, since the Particle's position has already been updated and there is no way of knowing where it was at the previous step.
One of the "special cases" I can think about has to do with some strategies that can only apply to PSO. For instance, if a particle's position exits the valid domain, then you can change the velocity (invert/deflect etc.) to compensate. This implies some tight coupling between velocity update and the position update, and only applies to PSO. It can get interesting in the many permutations generated by the above approach (do you restrict the particle's position, and only modify the velocity? or do you let the particle venture into invalid space and hope the change to the velocity vector brings it back?).
I'm not sure how Wian manages his constraints for the constraint-based optimization algorithms. That should (in my opinion) influence the way this gets handled across different algorithms, with support for special cases (like the one mentioned above).
We'll need to investigate more. I'll paste some discussion on the devel mailing list rather than here.