demo/so:
	
	four_corners.proj.gz		clustering-style so learning
					
	som.proj.gz			self-organizing maps
					
	bpso_som_coord.proj.gz		som + bp

four_corners.proj.gz:
=====================
This project as a "control" script object associated with it that
makes it easy to try out different combinations of learning rules and
activation functions.  This script creates a dialog that comes up
automatically when the project is loaded (it will be under the mouse,
but also possibly under other windows, so you might have to look for
it a bit).  This has 'Activation' and 'Learning' menus which select
which type of function to use.

The environment these networks experience has four "clusters" of
patterns, which are arranged around the four corners of the 5x5 input
grid.  Thus, each of the four output units is supposed to end up
representing one of the corners of the input grid.  This problem is
challenging for self-organizing networks because there is some amount
of overlap between the different clusters, so often they end up not
making clean clusters of the inputs.  You can tinker around with the
different algorithms and parameters to see what variables affect
performance.

There is a special statistic associated with the testing process which
compares the pattern of activity for the units over the test epoch of
all 20 events with a set of 4 activity patterns that correspond to a
unit responding perfectly to one of the 4 clusters.  Thus, the
correlation between these "target" patterns of activity over time
gives a measure of how well the network has pulled apart the
categories.  This is plotted in one of the grid logs.  The average of
these correlations over an entire batch of networks is given by
another grid log, which is updated by the batch process.

The button "TrainAndTest" will train the network for 100 epochs, then
test it and compute is correlation measure.  The button "BatchRun"
will run 5 batches of training and testing.  Also, the button
"UpdateSpecs" should be used whenever any of the parameters in the
dialog are changed, to make sure that all of the sub-specs have the
same parameters as their parents.

Try looking at the weights that result and see how they differ for the
different algorithms.  This can be quite informative.

Note that when you use the HebbConSpec, you will have to switch the
environment to use -1,1 values, which can be done in the 'EnvRange'
menu of the control script object.


som.proj.gz:
============
This project demonstrates the use of the self-organizing map
algorithm.  It has an environment which is automatically-generated
(using a ScriptEnv) to produce two random numbers on the two input
units.  These numbers are then "mapped" into a topographically
organized 10x10 output layer.  Since the numbers are uniformly
distributed between 0 and 1, the mapping should organize into two
orthogonal "planes" of weights, one for each input unit.  This can be
seen by viewing the s.wt of the two input units (their sending weights
to the output layer).

The kernel of the activation function can be observed by looking at
the activations as the network is tested or trained.  Its instructive
to try out different kernel functions, which can be done by editing
the 'SomLayerSpec'.

The testing process iterates through an environment with an inner and
outer-loop of activations of the input units, where the right-most
input goes from 0-1 for a given value of the left-most one, which is
incremented in an outer loop from 0-1.  When the network is tested
with these events, the center of activity should shift smoothly across
the output layer.  By using the Fast-forward button on the grid log,
one can view the shifting due to the left-most unit, while a given
panel shows the shifting due to the right-most unit.


bpso_som_coord.proj.gz:
=======================
This project is like som.proj.gz described above, except that it adds
an additional backprop network on top of the map layer generated by
the SOM.  This backprop net tries to convert the map activation into
an integer-valued coordinate representation of the two continuous
input values.  The first row of 10 output units represents the values
of the first input unit, and the second row the second.  Thus, it is
using the intermediate map representation to solve this task.  The two
networks are linked with a BridgeProcess, which is described in
greater detail in the 'bridge' demo directory. 

Since both bp and so algorithms are being used, this project must be
run with the bpso++ executable.
