Control Mechanisms¶

Sections¶

Overview

ControlMechanisms and a Composition

Creating a ControlMechanism

Specifying OutputStates to be monitored

Objective Mechanism

Specifying Parameters to Control

Structure

Input

Function

‘ControlMechanism_Output`

Costs and Net Outcome

Execution

Examples

Class Reference

Overview¶

A ControlMechanism is a Modulatory Mechanisms that modulates the value(s) of one or more States of other Mechanisms in the Composition to which it belongs. In general, a ControlMechanism is used to modulate the ParameterState(s) of one or more Mechanisms, that determine the value(s) of the parameter(s) of the function(s) of those Mechanism(s). However, a ControlMechanism can also be used to modulate the function of InputStates and/or OutputState, much like a Gating Mechanism. A ControlMechanism’s function calculates a control_allocation: a list of values provided to each of its control_signals. Its control_signals are ControlSignal OutputStates that are used to modulate the parameters of other Mechanisms’ function (see Modulation for a more detailed description of how modulation operates). A ControlMechanism can be configured to monitor the outputs of other Mechanisms in order to determine its control_allocation, by specifying these in the monitor_for_control argument of its constructor, or in the monitor argument of an ObjectiveMechanism` assigned to its objective_mechanism argument (see Creating a ControlMechanism below). A ControlMechanism can also be assigned as the controller of a Composition, which has a special relation to that Composition: it generally executes either before or after all of the other Mechanisms in that Composition (see Controller Execution). The OutputStates monitored by the ControlMechanism or its objective_mechanism, and the parameters it modulates can be listed using its show method.

ControlMechanisms and a Composition¶

A ControlMechanism can be assigned to a Composition and executed just like any other Mechanism. It can also be assigned as the controller of a Composition, that has a special relation to the Composition: it is used to control all of the parameters that have been specified for control in that Composition. A ControlMechanism can be the controller for only one Composition, and a Composition can have only one controller. When a ControlMechanism is assigned as the controller of a Composition (either in the Composition’s constructor, or using its add_controller method, the ControlMechanism assumes control over all of the parameters that have been specified for control for Components in the Composition. The Composition’s controller is executed either before or after all of the other Components in the Composition are executed, including any other ControlMechanisms that belong to it (see Controller Execution). A ControlMechanism can be assigned as the controller for a Composition by specifying it in the controller argument of the Composition’s constructor, or by using the Composition’s add_controller method. A Composition’s controller and its associated Components can be displayed using the Composition’s show_graph method with its show_control argument assigned as True.

Creating a ControlMechanism¶

A ControlMechanism is created by calling its constructor. When a ControlMechanism is created, the OutputStates it monitors and the States it modulates can be specified in the montior_for_control and objective_mechanism arguments of its constructor, respectively. Each can be specified in several ways, as described below. If neither of those arguments is specified, then only the ControlMechanism is constructed, and its inputs and the parameters it modulates must be specified in some other way.

Specifying OutputStates to be monitored¶

A ControlMechanism can be configured to monitor the output of other Mechanisms directly (by receiving direct Projections from their OutputStates), or by way of an ObjectiveMechanism that evaluates those outputs and passes the result to the ControlMechanism (see below for more detailed description). The following figures show an example of each:

_images/ControlMechanism_without_ObjectiveMechanism_fig.svg

_images/ControlMechanism_with_ObjectiveMechanism_fig.svg

Note that, in the figures above, the ControlProjections are designated with square “arrowheads”, and the ControlMechanisms are shown as septagons to indicate that their ControlProjections create a feedback loop (see Composition_Initial_Values_and_Feedback; also, see below regarding specification of a ControlMechanism and associated ObjectiveMechanism in a Composition’s add_linear_processing_pathway method).

Which configuration is used is determined by how the following arguments of the ControlMechanism’s constructor are specified (also see Examples):

monitor_for_control – a list of OutputState specifications. If the objective_mechanism argument is not specified (or is False or None) then, when the ControlMechanism is added to a Composition, a MappingProjection is created for each OutputState specified to the ControlMechanism’s OUTCOME input_state. If the objective_mechanism argument is specified, then the OutputStates specified in monitor_for_control are assigned to the ObjectiveMechanism rather than the ControlMechanism itself (see Objective Mechanism for details).

objective_mechanism – if this is specfied in any way other than False or None (the default), then an ObjectiveMechanism is created that projects to the ControlMechanism and, when added to a Composition, is assigned Projections from all of the OutputStates specified either in the monitor_for_control argument of the ControlMechanism’s constructor, or the monitor argument of the ObjectiveMechanism’s constructor (see Objective Mechanism for details). The objective_mechanism argument can be specified in any of the following ways:

False or None – no ObjectiveMechanism is created and, when the ControlMechanism is added to a Composition, Projections from the OutputStates specified in the ControlMechanism’s monitor_for_control argument are sent directly to ControlMechanism (see specification of monitor_for_control argument).

True – an ObjectiveMechanism is created that projects to the ControlMechanism, and any OutputStates specified in the ControlMechanism’s monitor_for_control argument are assigned to ObjectiveMechanism’s monitor argument instead (see Objective Mechanism for additional details).

a list of OutputState specifications; an ObjectiveMechanism is created that projects to the ControlMechanism, and the list of OutputStates specified, together with any specified in the ControlMechanism’s monitor_for_control argument, are assigned to the ObjectiveMechanism’s monitor argument (see Objective Mechanism for additional details).

a constructor for an ObjectiveMechanism – the specified ObjectiveMechanism is created, adding any OutputStates specified in the ControlMechanism’s monitor_for_control argument to any specified in the ObjectiveMechanism’s monitor argument . This can be used to specify the function used by the ObjectiveMechanism to evaluate the OutputStates monitored as well as how it weights those OutputStates when they are evaluated (see below for additional details).

an existing ObjectiveMechanism – for any OutputStates specified in the ControlMechanism’s monitor_for_control argument, an InputState is added to the ObjectiveMechanism, along with MappingProjection to it from the specified OutputState. This can be used to specify an ObjectiveMechanism with a custom function and weighting of the OutputStates monitored (see below for additional details).

The OutputStates monitored by a ControlMechanism or its objective_mechanism are listed in the ControlMechanism’s monitor_for_control attribute (and are the same as those listed in the monitor attribute of the objective_mechanism, if specified).

Note that the MappingProjections created by specification of a ControlMechanism’s monitor_for_control argument or the monitor argument in the constructor for an ObjectiveMechanism in the ControlMechanism’s objective_mechanism argument supercede any MappingProjections that would otherwise be created for them when included in the pathway argument of a Composition’s add_linear_processing_pathway method.

Objective Mechanism¶

If an ObjectiveMechanism is specified for a ControlMechanism (in the objective_mechanism argument of its constructor; also see Examples), it is assigned to the ControlMechanism’s objective_mechanism attribute, and a MappingProjection is created automatically that projects from the ObjectiveMechanism’s OUTCOME output_state to the OUTCOME input_state of the ControlMechanism.

The objective_mechanism is used to monitor the OutputStates specified in the monitor_for_control argument of the ControlMechanism’s constructor, as well as any specified in the monitor argument of the ObjectiveMechanism’s constructor. Specifically, for each OutputState specified in either place, an input_state is added to the ObjectiveMechanism. OutputStates to be monitored (and corresponding input_states) can be added to the objective_mechanism later, by using its add_to_monitor method. The set of OutputStates monitored by the objective_mechanism are listed in its monitor attribute, as well as in the ControlMechanism’s monitor_for_control attribute.

When the ControlMechanism is added to a Composition, the objective_mechanism is also automatically added, and MappingProjectons are created from each of the OutputStates that it monitors to its corresponding input_states. When the Composition is run, the value(s) of the OutputState(s) monitored are evaluated using the objective_mechanism’s function, and the result is assigned to its OUTCOME output_state. That value is then passed to the ControlMechanism’s OUTCOME input_state, which is used by the ControlMechanism’s function to determine its control_allocation.

If a default ObjectiveMechanism is created by the ControlMechanism (i.e., when True or a list of OutputStates is specified for the objective_mechanism argument of the constructor), then the ObjectiveMechanism is created with its standard default function (LinearCombination), but using PRODUCT (rather than the default, SUM) as the value of the function’s operation parameter. The result is that the objective_mechanism multiplies the values of the OutputStates that it monitors, which it passes to the ControlMechanism. However, if the objective_mechanism is specified using either a constructor for, or an existing ObjectiveMechanism, then the defaults for the ObjectiveMechanism class – and any attributes explicitly specified in its construction – are used. In that case, if the LinearCombination with PRODUCT as its operation parameter are still desired, this must be explicitly specified. This is illustrated in the following examples.

The following example specifies a Control Mechanisms that automatically constructs its objective_mechanism:

>>> from psyneulink import *
>>> my_ctl_mech = ControlMechanism(objective_mechanism=True)
>>> assert isinstance(my_ctl_mech.objective_mechanism.function, LinearCombination)
>>> assert my_ctl_mech.objective_mechanism.function.operation == PRODUCT

Notice that LinearCombination was assigned as the function of the objective_mechanism, and PRODUCT as its operation parameter.

By contrast, the following example explicitly specifies the objective_mechanism argument using a constructor for an ObjectiveMechanism:

>>> my_ctl_mech = ControlMechanism(objective_mechanism=ObjectiveMechanism())
>>> assert isinstance(my_ctl_mech.objective_mechanism.function, LinearCombination)
>>> assert my_ctl_mech.objective_mechanism.function.operation == SUM

In this case, the defaults for the ObjectiveMechanism’s class are used for its function, which is a LinearCombination function with SUM as its operation parameter.

Specifying the ControlMechanism’s objective_mechanism with a constructor also provides greater control over how ObjectiveMechanism evaluates the OutputStates it monitors. In addition to specifying its function, the monitor_weights_and_exponents argument can be used to parameterize the relative contribution made by the monitored OutputStates when they are evaluated by that function (see Examples).

Specifying Parameters to Control¶

This can be specified in either of two ways:

On a ControlMechanism itself

The parameters controlled by a ControlMechanism can be specified in the control_signals argument of its constructor; the argument must be a specification for one more ControlSignals. The parameter to be controlled must belong to a Component in the same Composition as the ControlMechanism when it is added to the Composition, or an error will occur.

On a Parameter to be controlled by the `controller <Composition.controller>` of a `Composition`

Control can also be specified for a parameter where the parameter itself is specified, in the constructor for the Component to which it belongs, by including a ControlProjection, ControlSignal or the keyword CONTROL in a tuple specification for the parameter. In this case, the specified parameter will be assigned for control by the controller of any Composition to which its Component belongs, when the Component is executed in that Composition (see ControlMechanisms and a Composition). Conversely, when a ControlMechanism is assigned as the controller of a Composition, a ControlSignal is created and assigned to the ControlMechanism for every parameter of any Component in the Composition that has been specified for control.

In general, a ControlSignal is created for each parameter specified to be controlled by a ControlMechanism. These are a type of OutputState that send a ControlProjection to the ParameterState of the parameter to be controlled. All of the ControlSignals for a ControlMechanism are listed in its control_signals attribute, and all of its ControlProjections are listed in its`control_projections <ControlMechanism.control_projections>` attribute. Additional parameters to be controlled can be added to a ControlMechanism by using its assign_params method to add a ControlSignal for each additional parameter. See Examples.

Structure¶

Input¶

By default, a ControlMechanism has a single (primary) input_state that is named OUTCOME. If the ControlMechanism has an objective_mechanism, then the OUTCOME input_state receives a single MappingProjection from the objective_mechanism’s OUTCOME OutputState (see Objective Mechanism for additional details). Otherwise, when the ControlMechanism is added to a Composition, MappingProjections are created that project to the ControlMechanism’s OUTCOME input_state from each of the OutputStates specified in the monitor_for_control argument of its constructor. The value of the ControlMechanism’s OUTCOME InputState is assigned to its outcome attribute), and is used as the input to the ControlMechanism’s function to determine its control_allocation.

Function¶

A ControlMechanism’s function uses its outcome attribute (the value of its OUTCOME InputState) to generate a control_allocation. By default, its function is assigned the DefaultAllocationFunction, which takes a single value as its input, and assigns that as the value of each item of control_allocation. Each of these items is assigned as the allocation for the corresponding ControlSignal in control_signals. This distributes the ControlMechanism’s input as the allocation to each of its control_signals. This same behavior also applies to any custom function assigned to a ControlMechanism that returns a 2d array with a single item in its outer dimension (axis 0). If a function is assigned that returns a 2d array with more than one item, and it has the same number of control_signals, then each ControlSignal is assigned to the corresponding item of the function’s value. However, these default behaviors can be modified by specifying that individual ControlSignals reference different items in control_allocation as their variable (see OutputState variable).

Output¶

The OutputStates of a ControlMechanism are ControlSignals (listed in its control_signals attribute). It has a ControlSignal for each parameter specified in the control_signals argument of its constructor, that sends a ControlProjection to the ParameterState for the corresponding parameter. The ControlSignals are listed in the control_signals attribute; since they are a type of OutputState, they are also listed in the ControlMechanism’s output_states attribute. The parameters modulated by a ControlMechanism’s ControlSignals can be displayed using its show method. By default, each ControlSignal is assigned as its allocation the value of the corresponding item of the ControlMechanism’s control_allocation; however, subtypes of ControlMechanism may assign allocations differently. The default_allocation attribute can be used to specify a default allocation for ControlSignals that have not been assigned their own default_allocation. The allocation is used by each ControlSignal to determine its intensity, which is then assigned to the value of the ControlSignal’s ControlProjection. The value of the ControlProjection is used by the ParameterState to which it projects to modify the value of the parameter it controls (see Modulation for description of how a ControlSignal modulates the value of a parameter).

Costs and Net Outcome¶

A ControlMechanism’s control_signals are each associated with a set of costs, that are computed individually by each ControlSignal when they are executed by the ControlMechanism. The costs last computed by the control_signals are assigned to the ControlMechanism’s costs attribute. A ControlMechanism also has a set of methods – combine_costs, compute_reconfiguration_cost, and compute_net_outcome – that can be used to compute the combined costs of its control_signals, a reconfiguration_cost based on their change in value, and a net_outcome (the value of the ControlMechanism’s OUTCOME input_state minus its combined costs), respectively (see ControlMechanism_Costs_Computation below for additional details). These methods are used by some subclasses of ControlMechanism (e.g., OptimizationControlMechanism) to compute their control_allocation. Each method is assigned a default function, but can be assigned a custom functions in a corrsponding argument of the ControlMechanism’s constructor (see links to attributes for details).

Reconfiguration Cost

A ControlMechanism’s reconfiguration_cost is distinct from the costs of the ControlMechanism’s ControlSignals, and in particular it is not the same as their adjustment_cost. The latter, if specified by a ControlSignal, is computed individually by that ControlSignal using its adjustment_cost_function, based on the change in its intensity from its last execution. In contrast, a ControlMechanism’s reconfiguration_cost is computed by its compute_reconfiguration_cost function, based on the change in its control_allocation ControlMechanism.control_allocation> from the last execution, that will be applied to all of its control_signals. By default, compute_reconfiguration_cost is assigned as the Distance function with the EUCLIDEAN metric).

Execution¶

If a ControlMechanism is assigned as the controller of a Composition, then it is executed either before or after all of the other Mechanisms executed in a TRIAL for that Composition, depending on the value assigned to the Composition’s controller_mode attribute (see Controller Execution). If a ControlMechanism is added to a Composition for which it is not a controller, then it executes in the same way as a ProcessingMechanism, based on its place in the Composition’s graph. Because ControlProjections are likely to introduce cycles (recurrent connection loops) in the graph, the effects of a ControlMechanism and its projections will generally not be applied in the first TRIAL (see feedback argument for the add_projection method of Composition for a description of how to configure the initialization of feedback loops in a Composition; also see Scheduler for a description of detailed ways in which a GatingMechanism and its dependents can be scheduled to execute).

The ControlMechanism’s function takes as its input the value of its OUTCOME input_state (also contained in outcome). It uses that to determine the control_allocation, which specifies the value assigned to the allocation of each of its ControlSignals. Each ControlSignal uses that value to calculate its intensity, as well as its cost to modulate the value of the ParameterState(s) for the parameter(s) it controls, which are then used in the subsequent TRIAL of execution.

Note

States that receive a ControlProjection does not update its value until its owner Mechanism executes (see Lazy Evaluation for an explanation of “lazy” updating). This means that even if a ControlMechanism has executed, a parameter that it controls will not assume its new value until the Mechanism to which it belongs has executed.

Computation of Costs and Net_Outcome

Once the ControlMechanism’s function has executed, if compute_reconfiguration_cost has been specified, then it is used to compute the reconfiguration_cost for its control_allocation (see above. After that, each of the ControlMechanism’s control_signals calculates its cost, based on its intensity. The ControlMechanism then combines these with the reconfiguration_cost using its combine_costs function, and the result is assigned to the costs attribute. Finally, the ControlMechanism uses this, together with its outcome attribute, to compute a net_outcome using its compute_net_outcome function. This is used by some subclasses of ControlMechanism (e.g., OptimizationControlMechanism) to compute its control_allocation for the next TRIAL of execution.

Examples

The following example creates a ControlMechanism by specifying its objective_mechanism using a constructor that specifies the OutputStates to be monitored by its objective_mechanism and the function used to evaluated these:

>>> my_mech_A = ProcessingMechanism(name="Mech A")
>>> my_DDM = DDM(name="My DDM")
>>> my_mech_B = ProcessingMechanism(function=Logistic,
...                                            name="Mech B")

>>> my_control_mech = ControlMechanism(
...                          objective_mechanism=ObjectiveMechanism(monitor=[(my_mech_A, 2, 1),
...                                                                           my_DDM.output_states[RESPONSE_TIME]],
...                                                                     name="Objective Mechanism"),
...                          function=LinearCombination(operation=PRODUCT),
...                          control_signals=[(THRESHOLD, my_DDM),
...                                           (GAIN, my_mech_B)],
...                          name="My Control Mech")

This creates an ObjectiveMechanism for the ControlMechanism that monitors the primary OutputState of my_mech_A and the RESPONSE_TIME OutputState of my_DDM; its function first multiplies the former by 2 before, then takes product of their values and passes the result as the input to the ControlMechanism. The ControlMechanism’s function uses this value to determine the allocation for its ControlSignals, that control the value of the threshold parameter of my_DDM and the gain parameter of the Logistic Function for my_transfer_mech_B.

The following example specifies the same set of OutputStates for the ObjectiveMechanism, by assigning them directly to the objective_mechanism argument:

>>> my_control_mech = ControlMechanism(
...                             objective_mechanism=[(my_mech_A, 2, 1),
...                                                  my_DDM.output_states[RESPONSE_TIME]],
...                             control_signals=[(THRESHOLD, my_DDM),
...                                              (GAIN, my_mech_B)])

Note that, while this form is more succinct, it precludes specifying the ObjectiveMechanism’s function. Therefore, the values of the monitored OutputStates will be added (the default) rather than multiplied.

The ObjectiveMechanism can also be created on its own, and then referenced in the constructor for the ControlMechanism:

>>> my_obj_mech = ObjectiveMechanism(monitored_output_states=[(my_mech_A, 2, 1),
...                                                            my_DDM.output_states[RESPONSE_TIME]],
...                                      function=LinearCombination(operation=PRODUCT))

>>> my_control_mech = ControlMechanism(
...                        objective_mechanism=my_obj_mech,
...                        control_signals=[(THRESHOLD, my_DDM),
...                                         (GAIN, my_mech_B)])

Here, as in the first example, the constructor for the ObjectiveMechanism can be used to specify its function, as well as the OutputState that it monitors.

Class Reference¶

class psyneulink.core.components.mechanisms.modulatory.control.controlmechanism.ControlMechanism(system=None, monitor_for_control=None, objective_mechanism=None, function=Linear, default_allocation=None, control_signals=None, modulation=MULTIPLICATIVE, combine_costs=np.sum, compute_reconfiguration_cost=None, compute_net_outcome=lambda x, y:x-y, params=None, name=None, prefs=None)¶

Subclass of ModulatoryMechanism that modulates the parameter(s) of one or more Component(s).

Parameters:

system (System or bool : default None) – specifies the System to which the ControlMechanism should be assigned as its controller.
monitor_for_control (List[OutputState or Mechanism] : default None) – specifies the OutputStates to be monitored by the ObjectiveMechanism, if specified in the objective_mechanism argument (see Objective Mechanism), or directly by the ControlMechanism itself if an objective_mechanism is not specified. If any specification is a Mechanism (rather than its OutputState), its primary OutputState is used (see Specifying OutputStates to be monitored for additional details).
objective_mechanism (ObjectiveMechanism or List[OutputState specification] : default None) – specifies either an ObjectiveMechanism to use for the ControlMechanism, or a list of the OutputStates it should monitor; if a list of OutputState specifications is used, a default ObjectiveMechanism is created and the list is passed to its monitor argument, along with any OutputStates specified in the ControlMechanism’s monitor_for_control argument.
function (TransferFunction : default Linear(slope=1, intercept=0)) – specifies function used to combine values of monitored OutputStates.
default_allocation (number, list or 1d array : None) – specifies the default_allocation of any control_signals for which the default_allocation was not specified in its constructor (see default_allocation <ControlMechanism.default_allocation>` for additional details).
control_signals (ControlSignal specification or List[ControlSignal specification, ..]) – specifies the parameters to be controlled by the ControlMechanism; a ControlSignal is created for each (see Specifying ControlSignals for details of specification).
modulation (ModulationParam : MULTIPLICATIVE) – specifies the default form of modulation used by the ControlMechanism’s ControlSignals, unless they are individually specified.
combine_costs (Function, function or method : default np.sum) – specifies function used to combine the cost of the ControlMechanism’s control_signals; must take a list or 1d array of scalar values as its argument and return a list or array with a single scalar value.
compute_reconfiguration_cost (Function, function or method : default None) – specifies function used to compute the ControlMechanism’s reconfiguration_cost; must take a list or 2d array containing two lists or 1d arrays, both with the same shape as the ControlMechanism’s control_allocation attribute, and return a scalar value.
compute_net_outcome (Function, function or method : default lambda outcome, cost: outcome-cost) – function used to combine the values of its outcome and costs attributes; must take two 1d arrays (outcome and cost) with scalar values as its arguments and return an array with a single scalar value.
params (Dict[param keyword: param value] : default None) – a parameter dictionary that can be used to specify the parameters for the Mechanism, parameters for its function, and/or a custom function and its parameters. Values specified for parameters in the dictionary override any assigned to those parameters in arguments of the constructor.
name (str : default see name) – specifies the name of the ControlMechanism.
prefs (PreferenceSet or specification dict : default Mechanism.classPreferences) – specifies the PreferenceSet for the ControlMechanism; see prefs for details.

system¶: System_Base – The System for which the ControlMechanism is a controller. Note that this is distinct from a Mechanism’s systems attribute, which lists all of the Systems to which a Mechanisms belongs – a ControlMechanism can belong to but not be the controller of a System.

objective_mechanism¶: ObjectiveMechanism – ObjectiveMechanism that monitors and evaluates the values specified in the ControlMechanism’s objective_mechanism argument, and transmits the result to the ControlMechanism’s OUTCOME input_state.

monitor_for_control¶: List[OutputState] – each item is an OutputState monitored by the ControlMechanism or its objective_mechanism if that is specified (see Specifying OutputStates to be monitored); in the latter case, the list returned is ObjectiveMechanism’s monitor attribute.

monitored_output_states_weights_and_exponents¶: List[Tuple(float, float)] – each tuple in the list contains the weight and exponent associated with a corresponding OutputState specified in monitor_for_control; if objective_mechanism is specified, these are the same as those in the ObjectiveMechanism’s monitored_output_states_weights_and_exponents attribute, and are used by the ObjectiveMechanism’s function to parametrize the contribution made to its output by each of the values that it monitors (see ObjectiveMechanism Function).

input_state¶: InputState – the ControlMechanism’s primary InputState, named OUTCOME; this receives a MappingProjection from the OUTCOME OutputState of objective_mechanism if that is specified; otherwise, it receives MappingProjections from each of the OutputStates specifed in monitor_for_control (see _ControlMechanism_Input for additional details).

outcome¶: 1d array – the value of the ControlMechanism’s OUTCOME input_state.

function¶: TransferFunction : default Linear(slope=1, intercept=0) – determines how the value s of the OutputStates specified in the monitor_for_control argument of the ControlMechanism’s constructor are used to generate its control_allocation.

default_allocation¶: number, list or 1d array – determines the default_allocation of any control_signals for which the default_allocation was not specified in its constructor; if it is None (not specified) then the ControlSignal’s parameters.allocation.default_value is used. See documentation for default_allocation argument of ControlSignal constructor for additional details.

control_allocation¶: 2d array – each item is the value assigned as the allocation for the corresponding ControlSignal listed in the control_signals attribute; the control_allocation is the same as the ControlMechanism’s value attribute).

control_signals¶: ContentAddressableList[ControlSignal] – list of the ControlSignals for the ControlMechanism, including any inherited from a Composition for which it is a controller (same as ControlMechanism’s output_states attribute); each sends a ControlProjection to the ParameterState for the parameter it controls

compute_reconfiguration_cost¶: Function, function or method – function used to compute the ControlMechanism’s reconfiguration_cost; result is a scalar value representing the difference — defined by the function — between the values of the ControlMechanism’s current and last control_alloction, that can be accessed by reconfiguration_cost attribute.

reconfiguration_cost¶

scalar – result of compute_reconfiguration_cost function, that computes the difference between the values of the ControlMechanism’s current and last control_alloction; value is None and is ignored if compute_reconfiguration_cost has not been specified.

A ControlMechanism’s reconfiguration_cost is not the same as the adjustment_cost of its ControlSignals (see Reconfiguration Cost for additional details).

costs¶: list – current costs for the ControlMechanism’s control_signals, computed for each using its compute_costs method.

combine_costs¶: Function, function or method – function used to combine the cost of its control_signals; result is an array with a scalar value that can be accessed by combined_costs.

Note

This function is distinct from the combine_costs_function of a ControlSignal. The latter combines the different costs for an individual ControlSignal to yield its overall cost; the ControlMechanism’s combine_costs function combines those costs for its control_signals.

combined_costs¶: 1d array – result of the ControlMechanism’s combine_costs function.

compute_net_outcome¶: Function, function or method – function used to combine the values of its outcome and costs attributes; result is an array with a scalar value that can be accessed by the the net_outcome attribute.

net_outcome¶: 1d array – result of the ControlMechanism’s compute_net_outcome function.

control_projections¶: List[ControlProjection] – list of ControlProjections, one for each ControlSignal in control_signals.

modulation¶: ModulationParam – the default form of modulation used by the ControlMechanism’s ControlSignals, unless they are individually specified.

name¶: str – the name of the ControlMechanism; if it is not specified in the name argument of the constructor, a default is assigned by MechanismRegistry (see Naming for conventions used for default and duplicate names).

prefs¶: PreferenceSet or specification dict – the PreferenceSet for the ControlMechanism; if it is not specified in the prefs argument of the constructor, a default is assigned using classPreferences defined in __init__.py (see PreferenceSet for details).

add_to_monitor(monitor_specs, context=None)¶

Instantiate OutputStates to be monitored by ControlMechanism’s objective_mechanism.

monitored_output_states can be any of the following:

If any item is a Mechanism, its primary OutputState is used. OutputStates must belong to Mechanisms in the same System as the ControlMechanism.

assign_as_controller(system: psyneulink.core.components.shellclasses.System_Base, context=None)¶

Assign ControlMechanism as controller for a System.

system must be a System for which the ControlMechanism should be assigned as the controller. If the specified System already has a controller, it will be replaced by the current one, and the current one will inherit any ControlSignals previously specified for the old controller or the System itself. If the current one is already the controller for another System, it will be disabled for that System.

control_signals: Get ControlSignals from OutputStates

outputStateTypes¶: alias of ControlSignal

show()¶: Display the OutputStates monitored by ControlMechanism’s objective_mechanism and the parameters modulated by its control_signals.

class psyneulink.core.components.mechanisms.modulatory.control.controlmechanism.DefaultAllocationFunction(default_variable=None, params=None, owner=None)¶: Take a single 1d item and return a 2d array with n identical items Takes the default input (a single value in the OUTCOME InputState of the ControlMechanism), and returns the same allocation for each of its control_signals.