The Algorithm Interface

The Algorithm interface represents the algorithm that adjusts the models of the map so that the map approximates the distribution of the data patterns.  Every algorithm uses data, a map, and some parameters, so the Algorithm interface specifies methods for accessing and setting these objects.  It also specifies two control methods for starting and stopping the algorithm.

Figure 1.  UML diagram for the Algorithm interface.

JSOMap provides a skeletal implementation of the Algorithm interface, called AbstractAlgorithm.  This abstract class implements everything in the Algorithm interface except the actual SOM algorithm.  Classes representing various forms of the SOM algorithm can then extend AbstractAlgorithm and simply override the start method.

Figure 2.  UML diagram for the Algorithm implementations.

The start method in classes that extend AbstractAlgorithm should look something like:

public void start() {
    super.start();

    //get parameters from the Parameters object
    for (int k=0, max=getParameters().getIterations(); k<max && isExecuting(); k++) {
        //calculate some information using the data patterns and the map

        //update the models using the calculated information
    }
}

The start method in AbstractAlgorithm must be called first so that some initialization can take place.  Then, a for-loop carries out each iteration of the algorithm.  The for-loop should also test the isExecuting method for continuation at each iteration.  This allows the algorithm to be halted via the stop method.

JSOMap provides implementations of two classic SOM algorithms: the online version and the batch version.  Each implementation extends AbstractAlgorithm and uses the above format for the start method.  

Note that the online and batch SOM algorithms simply state rules for adjusting the models.  These rules can be applied to any type of pattern.  Traditionally, the patterns were vectors.  However, by having the Algorithm implementation delegate the actual model updating to another object, the basic idea behind the online and batch algorithms can be used with any type of pattern.  These model updating classes are OnlineUpdater and BatchUpdater.

Figure 3.  UML diagram for the model updaters.

For example, the start method in OnlineAlgorithm looks something like this:

public void start() {
    super.start();

    //get parameters from the Parameters object
    for (int k=0, max=getParameters().getIterations(); k<max && isExecuting(); k++) {
        //get the next pattern

        //find the node with the model most similar to the pattern

        //update the models
        for (int i=0, count=map.count(); i<count; i++) {
            updater.update(map.getModel(i), map.getNode(winner), map, kernel, pattern, k);
        }
    }

}

It determines the winning node by comparing the pattern and models using a generic distance metric (see the Parameters section) and then delegates the actual model updating to the OnlineUpdater implementation.  Thus, OnlineAlgorithm never has to know the actual type of the patterns it is working with; only other objects, such as the distance metric and model updater, have to know this.  The BatchAlgorithm uses a BatchUpdater object in the same manner.  There should be an implementation of OnlineUpdater and BatchUpdater for each type of concrete Pattern implementation.  It is also a good idea to create a new updater interface for any new types of SOM algorithm.

JSOMap also specifies two subinterfaces of Algorithm: EventAlgorithm and ControlAlgorithm.  EventAlgorithm is an algorithm that sends events to algorithm listeners and ControlAlgorithm allows fine control over the execution of the SOM algorithm.

Figure 4.  UML diagram for the Algorithm subinterfaces.

JSOMap provides skeletal implementations for the EventAlgorithm and ControlAlgorithm interfaces, as well as online and batch SOM algorithm implementations of them as well.

Figure 5.  UML diagram for the Algorithm implementations.

The start method of an EventAlgorithm implementation (that extends AbstractEventAlgorithm) should add the appropriate event firing method calls, so that it looks something like this:

public void start() {
    super.start();

    //get parameters from the Parameters object
    fireAlgorithmStarted(this, 0);
    int k = 0;
    for (int max=getParameters().getIterations(); k<max && isExecuting(); k++) {
        fireNextIteration(this, k);

        //calculate some information using the data patterns and the map

        //update the models using the calculated information
    }

    fireAlgorithmStopped(this, k);
}

See the Events section for more information about algorithm events.

Similarly, a ControlAlgorithm implementation (that extends AbstractControlAlgorithm) should add code to pause the algorithm, delay each iteration, and step through iterations one-by-one:

public void start() {
    super.start();

    //get parameters from the Parameters object
    fireAlgorithmStarted(this, 0);
    int k = 0;
    for (int max=getParameters().getIterations(); k<max && isExecuting(); k++) {
        //check for pausing & stepping
        while (isPaused() && !isStepping()) { doPause(); }

        fireNextIteration(this, k);

        //calculate some information using the data patterns and the map

        //update the models using the calculated information

        //do the delay, except after the last iteration & not when stepping
        if (k < params.getIterations() && !isStepping()) { doDelay(getDelay()); }
        //otherwise it means we were stepping, so pause the algorithm again
        else { pause(); }
    }

    fireAlgorithmStopped(this, k);
}

By creating an EventAlgorithm and ControlAlgorithm implementation for each Algorithm implementation, users can choose which type to use, from a basic algorithm to a finely controlled algorithm.

Send mail to zcox@iastate.edu with questions or comments about this web site.
Last modified: March 04, 2002