Computational Intelligence Library

We'll need to investigate more. I'll paste some discussion on the devel
mailing list rather than here.

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).

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.

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?

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.