Most TrialProcess objects are implemented to work with a particular set of network objects that are part of a given algorithm. Thus, the BpTrial process expects to operate on BpUnits and BpCons, etc., and crashes otherwise. This makes processing faster than if it had to check the type of every object operated on every time it did a computation.
This situation makes it difficult to implement hybrid networks which combine components that operate under two different algorithms. For example, a self-organizing network can be used to pre-process inputs to a backprop network.
The way to do solve this problem in PDP++ is to use a BridgeProcess, in conjunction with a SyncEpochProc as described in the previous section. Thus, there are two trial processes that each operate synchronously within an epoch on the same events. The bridge process copies activations or any other unit state variable from one network to the other, allowing them to act as if they were a single composite network.
An example of a bridge process can be found in the `demo/bridge' directory. This example just connects two backprop networks, but the principles are the same when you use two different kinds of algorithms.
The parameters of the bridge process are as follows:
Network* second_network
network
pointer).
BridgeDirection direction
network
pointer
and network two is the second_network
pointer. Note that the
network
pointer is set by the process hierarchy that this process
is in, which means that it can't be set arbitrarily. This is why one
might need to switch the direction with this field.
String src_layer_nm
String trg_layer_nm
String src_variable
String trg_variable
Unit::ExtType trg_ext_flag
InitExterns
call which usually precedes application of
environmental patterns.