OK, I just thought it would be more inline with the non-normalised version
where it clamps to the upper-bound.


On 3 April 2014 11:10, arakitianskaia <notifications@github.com> wrote:

> In
> library/src/main/java/net/sourceforge/cilib/pso/velocityprovider/NormalisedClampingVelocityProvider.java:
>
> > +    }
> > +
> > +    public NormalisedClampingVelocityProvider(NormalisedClampingVelocityProvider copy) {
> > +        this.vMax = copy.vMax.getClone();
> > +        this.delegate = copy.delegate.getClone();
> > +    }
> > +
> > +    @Override
> > +    public NormalisedClampingVelocityProvider getClone() {
> > +        return new NormalisedClampingVelocityProvider(this);
> > +    }
> > +
> > +    @Override
> > +    public Vector get(Particle particle) {
> > +        Vector velocity = (Vector) this.delegate.get(particle);
> > +        if(velocity.norm() > vMax.getParameter()) return velocity.normalize();
>
> There is no standard way of doing it, and normalised velocity clamping has
> not been documented anywhere in the published literature yet, but logically
> it makes sense to normalise without multiplying by the Vmax parameter: the
> whole point of clamping is making sure velocities don't explode. I.e., we
> care for the upper bound more than for the lower bound. Maybe we can
> implement another version of normalised clamping where the velocity vector
> is multiplied by Vmax, but I think this version should also stay. In this
> case, the Vmax parameter is more of a sensitivity threshold than anything
> else.
>
> --
>
> Reply to this email directly or view it on GitHub<https://github.com/cilib/cilib/pull/206/files#r11243764>
> .
>
>