12.2.1 Variables and Functions used in a SchedProcess

The SchedProcess provides the following variables and functions (in addition to the ones already provided by the basic Process):

12.3 Variables

bool can_stop
This variable is a flag that controls whether the SchedProcess can be interrupted during execution. This also determines if GUI events are being processed. Things can be speeded up a bit if this flag is turned off for low-level processes like the CycleProcess.
TypeDef sub_proc_type
This is type of process the sub_proc should be. If the sub_proc type does not inherit from this type then a new sub_proc is created of the correct type.
SchedProcess* sub_proc
This is a pointer to the child Process (if it exists) of this SchedProcess. This is the sub process that the process iterates over.
StepParams step
It is possible to single-step (or multiple step) through processing, and this controls how the Step function behaves. The step variable contains a pointer to the sub-process under the current one that represents the time-grain at which stepping should occur. The number of times this step process is iterated per each Step (i.e., each time the user hits the Step button) is determined by the n parameter.
Stat_Group loop_stats
This is a group that contains the Statistic processes that will be executed within the loop of the schedule process (i.e., called by LoopStats() in the loop code shown above). Thus, for a epoch process, these stats will be computed after every trial, since the epoch process loops over trials. These are typically aggregation stats, which are adding up values computed in the trial process. For example the epoch sum of squares error would be aggregated in the epoch loop stats.
Stat_Group final_stats
This is a group that contains the Statistic processes that will be executed at the end of the loop for this process. This is typically where statistics go which are computed for the first time (i.e., not those that are simply aggregating values computed lower down in the hierarchy).
Process_Group init_procs
This contains miscellaneous processes that get executed when the process is initialized. Note that these are run only when the process is actually running, not when the ReInit or NewInit buttons are hit. Thus, if you hit one of these buttons, and then do a Run, the first thing that will happen when the process is run is that the init_procs will be executed.
Process_Group loop_procs
These are miscellaneous processes that get executed inside the loop of the process. For example, it is possible to link in a testing epoch process into the loop_procs of a training TrainProcess, with a mod value set to 10, for example, which will result in the network being tested after every 10 epochs of training.
Process_Group final_procs
These are miscellaneous processes that get executed after the loop of the process, just before the final stats are computed.
bool log_loop
Either the process sends its data at the end of its processing loop, which is the "natural" (and default) way to do things, since it corresponds with the name of the process (the end of the epoch process means once every epoch, while the loop of the epoch process is actually the end of every trial!), or it sends its data inside the loop, which can be useful to see the aggregation of the loop_stats statistics over time. This flag, if checked, means that it logs inside the loop.
bool log_counter
This flag determines if the counter associated with this process (e.g., the epoch counter in the TrainProcess) is logged along with all the other data that is logged.

Many of the core functions on the schedule process object were documented in the main loop code shown previously. In addition to the functions on the process object, the following functions are available in a schedule process (most can be found in the Actions menu of the edit dialog or control panel).

InitMyLogs()
Clear all logs that this process updates.
InitAllLogs()
Clear all logs that exist in the Project that this SchedProcess is in.
InitNetwork()
Initialize the weights in the network associated with this process (calls InitWtState() on the network).
InitAll();
Initialize the process, network weights, and logs.
RemoveFromLogs();
Remove this SchedProcess from all the logs in the logs group and clear out the logs group.
RemoveFromDisplays();
Remove this SchedProcess from all the displays in the displays group and clear out the displays group.
CheckAllTypes();
This goes through all the objects in the network and makes sure that they are all of the minimum type necessary for all of the processes statistics being computed by this processing hierarchy. This is done automatically whenever the training process is initialized, but it can be done manually just to make sure. This check is useful, especially if you are experiencing unexplained crashing, because many process objects assume that the objects in the network are of the appropriate type.

The following are a set of functions that are particularly useful for configuring the processing hierarchy, and appear in the Structure menu of a SchedProc.

MoveToSubGp(const char* gp_name)
This moves the current process and all of its sub-processes to a new sub-group within the .processes group of the project. Run this on the top-level process in a process hierarchy. This is useful for organizing the menu when several processing hierarchies are present in the same project.
ChangeNameSuffix(const char* new_name_sufx)
This changes the portion of the sched process names after the underbar (_) to the new specified name. This is the preferred way to give a whole hierarchy of sched procs the same semantically meaningful tag (e.g., a suffix of "Trn" for training processes, and "Tst" for testing processes.) Run this on the top level process, as it works on all sub-processes.
AddSuperProc(TypeDef* type)
This will add a new schedule process above this one, of the given type, while preserving as much of the existing structure as possible. Thus, any aggregated stats will be aggregated through the new super proc, and it is inserted so that any previous super proc is now the super proc to the new super proc, etc.
AddSubProc(TypeDef* type)
Like AddSuperProc, but adds a new process below this one.
RemoveSuperProc(TypeDef* type)
This is effectively the inverse of AddSuperProc -- removes parent process and closes up any existing aggregation links, etc.
RemoveSubProc(TypeDef* type)
This is effectively the inverse of AddSubProc -- removes sub process and closes up any existing aggregation links, etc.