Layers are basically just groups of units, but they also constitute the basic elements of connectivity as specified by the projections (see section 10.3 Projections). Thus, one can specify that a whole group of units should be connected in a particular fashion to another whole group of units, instead of going one-by-one through the units and telling each one individually how to connect to other units. Note that the model used in PDP++ is the receiver model -- a layer contains the projections it receives from other layers, not the ones it sends to them.
Further, in certain kinds of learning algorithms, particularly those with a self-organizing character, the Layer plays a computational role in that it implements competition among units, for example (see section 16 Self-organizing Learning). In these algorithms, the Layer will have an accompanying LayerSpec that contains the parameters governing the computation that occurs in the layer. However, in standard backpropagation and constraint satisfaction algorithms (section 14 Backpropagation, section 15 Constraint Satisfaction), the LayerSpec is not used.
Layers have the following variables:
int n_units
Geometry geom
n_units
. Note that a
z
value of greater than 1 means that multiple sub-groups of units
will be created in the layer, each of which having x * y units (by
default).
Geometry pos
Geometry gp_geom
geom.z > 1
). Groups will be arranged in the
x,y geometry given by this parameter (i.e., x * y
should be >=
geom.z
).
Projection_Group projections
Unit_Group units
el_typ
on this group
(see section 8.2.2 Group Variables). Note that sub-groups of units can be
created, as given by the geom.z
parameter, and as described
in greater detail below.
UnitSpec_SPtr unit_spec
bool lesion
true
, this layer is inactivated from all processing,
as if it was not there in the first place. This makes it possible to
selectively pre-train certain layers within the network, for example.
Unit:ExtType ext_flag
The following layer functions are available, either in the layer edit dialog or in the CSS script language:
Build()
n_units
in the layer and arrange them according to the
geometry
. If units already exist, they are enforced to be of
the type of the unit group. Thus, the best way to change the type of
units in the layer is to change the el_typ
of the units group and
then do a Build() (see also section 10.1 The Network Object).
Connect()
RemoveCons()
DisConnect()
RemoveCons
in
that it removes the projections as well as the connections.
Copy_Weights(Layer *)
SetLayerSpec(LayerSpec *)
SetUnitSpec(UnitSpec *)
SetConSpec(ConSpec *)
Note that the layer also has instances of other functions that are
present on the network, such as InitWtState
and InitState
.
The Unit_Group provides another level of organization between the layer and the units within the layer. This can be useful for cases where different groups of units play specialized roles, but have otherwise the same connectivity to other layers (which is what makes them part of the same layer instead of being different layers). This level of organization has been used to implement independent sub-pools of activation competition within a larger layer, for example.
Unit groups are created as sub-groups within the units
member of
the layer. The z
value of the layer's geometry specification
indicates how many groups to create, and each of them has n_units
units arranged in the geom.x, geom.y
geometry as specified in the
layer. However, once created, the unit groups can be individually
re-sized, and they have their own n_units
, geom
, and
pos
variables. To have a unit group always use the settings on
the layer, the n_units
should be set to 0.