InputState

Overview

The purpose of an InputState is to receive and combine inputs to a Mechanisms, allow them to be modified, and provide them to the Mechanism’s function. An InputState receives input to a Mechanisms provided by the Projections to that Mechanism from others in a Process or System. If the InputState belongs to an ORIGIN Mechanism (see role of Mechanisms in Processes and Systems), then it receives the input specified when that Process or System is run. The PathwayProjections received by an InputState are listed in its path_afferents, and its ModulatoryProjections in its mod_afferents attribute. Its function combines the values received from its PathWayProjections, modifies the combined value according to value(s) any ModulatoryProjections it receives, and provides the result to the assigned item of its owner Mechanism’s variable and input_values attributes (see below and Mechanism InputStates for additional details about the role of InputStates in Mechanisms, and their assignment to the items of a Mechanism’s variable attribute).

Creating an InputState

An InputState can be created by calling its constructor, but in general this is not necessary as a Mechanisms can usually automatically create the InputState(s) it needs when it is created. For example, if the Mechanism is being created within the pathway of a Process, its InputState is created and assigned as the receiver of a MappingProjection from the preceding Mechanism in the pathway. InputStates can also be specified in the input_states argument of a Mechanism’s constructor (see below).

The variable of an InputState can be specified using the variable or size arguments of its constructor. It can also be specified using the projections argument, if neither variable nor size is specified. The projections argument is used to specify Projections to the InputState. If neither the variable nor size arguments is specified, then the value of the Projections(s) or their senders (all of which must be the same length) is used to determine the variable of the InputState.

If an InputState is created using its constructor, and a Mechanism is specified in the owner argument, it is automatically assigned to that Mechanism. Note that its value (generally determined by the size of its variable – see below) must be compatible (in number and type of elements) with the item of its owner’s variable to which it is assigned (see below and Mechanism). If the owner argument is not specified, initialization is deferred.

Owner Assignment and Deferred Initialization

An InputState must be owned by a Mechanism. When InputState is specified in the constructor for a Mechanism (see below), it is automatically assigned to that Mechanism as its owner. If the InputState is created on its own, its owner can specified in the owner argument of its constructor, in which case it is assigned to that Mechanism. If its owner argument is not specified, its initialization is deferred until the InputState is assigned to a Mechanism using the Mechanism’s add_states method.

Primary InputState

Every Mechanism has at least one InputState, referred to as its primary InputState. If InputStates are not explicitly specified for a Mechanism, a primary InputState is automatically created and assigned to its input_state attribute (note the singular), and also to the first entry of the Mechanism’s input_states attribute (note the plural). The value of the primary InputState is assigned as the first (and often only) item of the Mechanism’s variable and input_values attributes.

InputState Specification

Specifying InputStates when a Mechanism is created

InputStates can be specified for a Mechanism when it is created, in the input_states argument of the Mechanism’s constructor (see examples in State), or in an INPUT_STATES entry of a parameter dictionary assigned to the constructor’s params argument. The latter takes precedence over the former (that is, if an INPUT_STATES entry is included in the parameter dictionary, any specified in the input_states argument are ignored).

Note

Assigning InputStates to a Mechanism in its constructor replaces any that are automatically generated for that Mechanism (i.e., those that it creates for itself by default). If any of those are needed, they must be explicitly specified in the list assigned to the input_states argument, or the INPUT_STATES entry of the parameter dictionary in the params argument. The number of InputStates specified must also be equal to the number of items in the Mechanism’s variable attribute.

InputState’s variable, value and Mechanism’s variable

Each InputState specified in the input_states argument of a Mechanism’s constructor must correspond to an item of the Mechanism’s variable attribute (see Mechanism), and the value of the InputState must be compatible with that item (that is, have the same number and type of elements). By default, this is also true of the InputState’s variable attribute, since the default function for an InputState is a LinearCombination, the purpose of which is to combine the inputs it receives and possibly modify the combined value (under the influence of any ModulatoryProjections it receives), but not mutate its form. Therefore, under most circumstances, both the variable of an InputState and its value should match the item of its owner’s variable to which the InputState is assigned.

The format of an InputState’s variable can be specified in a variety of ways. The most straightforward is in the variable argument of its constructor. More commonly, however, it is determined by the context in which it is being created, such as the specification for its owner Mechanism’s variable or for the InputState in the Mechanism’s input_states argument (see below and Mechanism InputState specification for details).

Adding InputStates to a Mechanism after it is created

InputStates can also be added to a Mechanism, either by creating the InputState on its own, and specifying the Mechanism in the InputState’s owner argument, or by using the Mechanism’s add_states method (see examples in State).

Note

Adding InputStates does not replace any that the Mechanism generates by default; rather they are added to the Mechanism, and appended to the list of InputStates in its input_states attribute. Importantly, the Mechanism’s variable attribute is extended with items that correspond to the value attribute of each added InputState. This may affect the relationship of the Mechanism’s variable to its function, as well as the number of its OutputStates (see note).

If the name of an InputState added to a Mechanism is the same as one that already exists, its name is suffixed with a numerical index (incremented for each InputState with that name; see Naming), and the InputState is added to the list (that is, it will not replace ones that already exist).

Forms of Specification

InputStates can be specified in a variety of ways, that fall into three broad categories: specifying an InputState directly; use of a State specification dictionary; or by specifying one or more Components that should project to the InputState. Each of these is described below:

Direct Specification of an InputState

  • InputState class, keyword INPUT_STATE, or a string – this creates a default InputState; if used to specify an InputState in the constructor for a Mechanism, the item of the owner Mechanism’s variable to which the InputState is assigned is used as the format for the InputState`s variable; otherwise, the default for the InputState is used. If a string is specified, it is used as the name of the InputState (see example).
  • value – this creates a default InputState using the specified value as the InputState’s variable; if used to specify an InputState in the constructor for a Mechanism, the format must be compatible with the corresponding item of the owner Mechanism’s variable (see Mechanism InputState specification, example, and discussion below).

InputState Specification Dictionary

  • InputState specification dictionary – this can be used to specify the attributes of an InputState, using any of the entries that can be included in a State specification dictionary (see examples in State). If the dictionary is used to specify an InputState in the constructor for a Mechanism, and it includes a VARIABLE and/or VALUE or entry, the value must be compatible with the item of the owner Mechanism’s variable to which the InputState is assigned (see Mechanism InputState specification).

    The PROJECTIONS entry can include specifications for one or more States, Mechanisms and/or Projections that should project to the InputState (including both MappingProjections and/or ModulatoryProjections; however, this may be constrained by or have consequences for the InputState’s variable (see InputState variable: Compatibility and Constraints).

    In addition to the standard entries of a State specification dictionary, the dictionary can also include either or both of the following entries specific to InputStates:

    • WEIGHT:<number>
      the value must be an integer or float, and is assigned as the value of the InputState’s weight attribute (see weight and exponent); this takes precedence over any specification in the weight argument of the InputState’s constructor.

    • EXPONENT:<number>
      the value must be an integer or float, and is assigned as the value of the InputState’s exponent attribute (see weight and exponent); this takes precedence over any specification in the exponent argument of the InputState’s constructor.

Specification of an InputState by Components that Project to It

An InputState can also be specified by specifying one or more States, Mechanisms or Projections that should project to it, as described below. Specifying an InputState in this way creates both the InputState and any of the specified or implied Projection(s) to it (if they don’t already exist). MappingProjections are assigned to the InputState’s path_afferents attribute, and GatingProjections to its mod_afferents attribute. Any of the following can be used to specify an InputState by the Components that projection to it (see below for an explanation of the relationship between the value of these Components and the InputState’s variable):

  • OutputState, GatingSignal, Mechanism, or list with any of these – creates an InputState with Projection(s) to it from the specified State(s) or Mechanism(s). For each Mechanism specified, its primary OutputState (or GatingSignal) is used.
  • InputState specification tuples – these are convenience formats that can be used to compactly specify an InputState and Projections to it any of the following ways:

    • 2-item tuple: (<State name or list of State names>, <Mechanism>) – 1st item must be the name of an OutputState or Modulatory Signals, or a list of such names, and the 2nd item must be the Mechanism to which they all belong. Projections of the relevant types are created for each of the specified States (see State 2-item tuple for additional details).

    • 2-item tuple: (<value, State specification, or list of State specs>, <Projection specification>) – this is a contracted form of the 4-item tuple described below;

    • 4-item tuple: (<value, State spec, or list of State specs>, weight, exponent, Projection specification) – this allows the specification of State(s) that should project to the InputState, together with a specification of the InputState’s weight and/or exponent attributes of the InputState, and (optionally) the Projection(s) to it. This can be used to compactly specify a set of States that project the InputState, while using the 4th item to determine its variable (e.g., using the matrix of the Projection specification) and/or attributes of the Projection(s) to it. Each tuple must have at least the following first three items (in the order listed), and can include the fourth:


      • value, State specification, or list of State specifications – specifies either the variable of the InputState, or one or more States that should project to it. The State specification(s) can be a (State name, Mechanism) tuple (see above), and/or include Mechanisms (in which case their primary OutputState is used. All of the State specifications must be consistent with (that is, their value must be compatible with the variable of) the Projection specified in the fourth item if that is included;

      • weight – must be an integer or a float; multiplies the value of the InputState before it is combined with others by the Mechanism’s function (see ObjectiveMechanism for examples);

      • exponent – must be an integer or float; exponentiates the value of the InputState before it is combined with others by the ObjectiveMechanism’s function (see ObjectiveMechanism for examples);

      • Projection specification (optional) – specifies a Projection that must be compatible with the State specification(s) in the 1st item; if there is more than one State specified, and the Projection specification is used, all of the States must be of the same type (i.e.,either OutputStates or GatingSignals), and the Projection Specification cannot be an instantiated Projection (since a Projection cannot be assigned more than one sender).

InputState variable: Compatibility and Constraints

The variable of an InputState must be compatible with the item of its owner Mechanism’s variable to which it is assigned (see Mechanism_Variable_and_InputStates>). This may have consequences that must be taken into account when specifying an InputState by Components that project to it. These depend on the context in which the specification is made, and possibly the value of other specifications. These considerations and how they are handled are described below, starting with constraints that are given the highest precedence:

default_variable argument for the Mechanism is also specified – the item of the variable to which the InputState is assigned is used to determine the InputState’s variable must. Any other specifications of the InputState relevant to its variable must be compatible with this (for example, specifying it by value or by a MappingProjection or OutputState that projects to it (see above).
  • If the InputState’s variable is not constrained by any of the conditions above, then its format is determined by the specification of Components that project to it:

    • More than one Component is specified with the same :ref:`value` format – that format is used to determine the format of the InputState’s variable.

    • More than one Component is specified with different :ref:`value` formats – the InputState’s variable is determined by item of the default variable for the class of its owner Mechanism.

    • A single Component is specified – its value is used to determine the format of the InputState’s variable; if the Component is a(n):

      • MappingProjection – can be specified by its class, an existing MappingProjection, or a matrix:


        • Existing MappingProjection – then its value determines the InputState’s variable.

        • Matrix specification – its receiver dimensionality determines the format of the InputState’s variable. For a standard 2d “weight” matrix (i.e., one that maps a 1d array from its sender to a 1d array of its receiver), the receiver dimensionality is its outer dimension (axis 1, or its number of columns). However, if the sender has more than one dimension, then the dimensionality of the receiver (used for the InputState’s variable) is the dimensionality of the matrix minus the dimensionality of the sender’s value (see matrix dimensionality).

      • OutputState or ProcessingMechanism – the value of the OutputState (if it is a Mechanism, then its primary OutputState) determines the format of the InputState’s variable, and a MappingProjection is created from the OutputState to the InputState using an IDENTITY_MATRIX. If the InputState’s variable is constrained (as in some of the cases above), then a FULL_CONNECTIVITY_MATRIX is used which maps the shape of the OutputState’s value to that of the InputState’s variable.

      • GatingProjection, GatingSignal or GatingMechanism – any of these can be used to specify an InputState; their value does not need to be compatible with the InputState’s variable, however it does have to be compatible with the modulatory parameter of the InputState’s function.

Structure

Every InputState is owned by a Mechanism. It can receive one or more MappingProjections from other Mechanisms, as well as from the Process or System to which its owner belongs (if it is the ORIGIN Mechanism for that Process or System). It has the following attributes, that includes ones specific to, and that can be used to customize the InputState:

  • mod_afferentsGatingProjections that project to the InputState, the value of which can modify the InputState’s value (see the descriptions of Modulation under ModulatorySignals and GatingSignals for additional details). If the InputState receives more than one GatingProjection, their values are combined before they are used to modify the value of InputState.
  • function – aggregates the value of all of the Projections received by the InputState, and assigns the result to the InputState’s value attribute. The default function is LinearCombination that performs an elementwise (Hadamard) sums the values. However, the parameters of the function – and thus the value of the InputState – can be modified by any GatingProjections received by the InputState (listed in its mod_afferents attribute. A custom function can also be specified, so long as it generates a result that is compatible with the item of the Mechanism’s variable to which the InputState is assigned.
  • weight and exponent – these can be used by the Mechanism to which the InputState belongs when that combines the values of its States (e.g., an ObjectiveMechanism uses the weights and exponents assigned to its InputStates to determine how the values it monitors are combined by its function). The value of each must be an integer or float, and the default is 1 for both.

Execution

An InputState cannot be executed directly. It is executed when the Mechanism to which it belongs is executed. When this occurs, the InputState executes any Projections it receives, calls its function to aggregate the values received from any MappingProjections it receives (listed in its its path_afferents attribute) and modulate them in response to any GatingProjections (listed in its mod_afferents attribute), and then assigns the result to the InputState’s value attribute. This, in turn, is assigned to the item of the Mechanism’s variable and input_values attributes corresponding to that InputState (see Mechanism Variable and InputStates for additional details).

Class Reference

class psyneulink.components.states.inputstate.InputState(owner=None, variable=None, size=None, function=LinearCombination(operation=SUM), combine=None, projections=None, weight=None, exponent=None, internal_only=False, params=None, name=None, prefs=None)

Subclass of State that calculates and represents the input to a Mechanism from one or more PathwayProjection.

Parameters:
  • owner (Mechanism) – the Mechanism to which the InputState belongs; it must be specified or determinable from the context in which the InputState is created.
  • reference_value (number, list or np.ndarray) – the value of the item of the owner Mechanism’s variable attribute to which the InputState is assigned; used as the template for the InputState’s value attribute.
  • variable (number, list or np.ndarray) – specifies the template for the InputState’s variable attribute.
  • size (int, list or np.ndarray of ints) – specifies variable as array(s) of zeros if variable is not passed as an argument; if variable is specified, it takes precedence over the specification of size.
  • function (Function or method : default LinearCombination(operation=SUM)) – specifies the function used to aggregate the values of the Projections received by the InputState, under the possible influence of GatingProjections received by the InputState. It must produce a result that has the same format (number and type of elements) as the item of its owner Mechanism’s variable to which the InputState has been assigned.
  • combine (SUM or PRODUCT : default None) – specifies the operation argument used by the default LinearCombination function, wnich determines how the value of the InputState’s projections are combined. This is a convenience argument, that operation to be specified without having to specify the function’s constructor; accordingly, it assumes that LinearCombination (the default) is used as the InputState’s function – if it conflicts with a specification of function an error is generated.
  • projections (list of Projection specifications) – specifies the MappingProjection(s) and/or GatingProjection(s) to be received by the InputState, and that are listed in its path_afferents and mod_afferents attributes, respectively (see InputState variable: Compatibility and Constraints for additional details). If projections but neither variable nor size are specified, then the value of the Projection(s) or their senders specified in projections argument are used to determine the InputState’s variable.
  • weight (number : default 1) – specifies the value of the weight attribute of the InputState.
  • exponent (number : default 1) – specifies the value of the exponent attribute of the InputState.
  • internal_only (bool : False) – specifies whether external input is required by the InputState’s owner if its role is EXTERNAL_INPUT (see internal_only for details).
  • params (Dict[param keyword: param value] : default None) – a parameter dictionary that can be used to specify the parameters for the InputState or 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 InputState; see InputState name for details.
  • prefs (PreferenceSet or specification dict : default State.classPreferences) – specifies the PreferenceSet for the InputState; see prefs for details.
owner

Mechanism – the Mechanism to which the InputState belongs.

path_afferents

List[MappingProjection]MappingProjections that project to the InputState (i.e., for which it is a receiver).

mod_afferents

List[GatingProjection]GatingProjections that project to the InputState.

projections

List[Projection] – all of the Projections received by the InputState.

variable

value, list or np.ndarray – the template for the value of each Projection that the InputState receives, each of which must match the format (number and types of elements) of the InputState’s variable. If neither the variable or size argument is specified, and projections is specified, then variable is assigned the value of the Projection(s) or its sender.

function

CombinationFunction : default LinearCombination(operation=SUM)) – performs an element-wise (Hadamard) aggregation of the value of each Projection received by the InputState, under the possible influence of any GatingProjections received by the InputState.

value

value or ndarray – the output of the InputState’s function, which is the the aggregated value of the PathwayProjections (e.g., MappingProjections) received by the InputState (and listed in its path_afferents attribute), possibly modulated by any GatingProjections it receives (listed in its mod_afferents attribute). The result (whether a value or an ndarray) is assigned to an item of the owner Mechanism’s variable.

label

string or number – the string label that represents the current value of the InputState, according to the owner mechanism’s input_labels_dict. If the current value of the InputState does not have a corresponding label, then the numeric value is returned.

weight

number – see weight and exponent for description.

exponent

number – see weight and exponent for description.

internal_only

bool – determines whether input is required for this InputState from Run or another Compositions when the InputState’s owner is executed, and its role is designated as EXTERNAL_INPUT; if True, external input is not required or allowed; otherwise, external input is required.

name

str – the name of the InputState; if it is not specified in the name argument of the constructor, a default is assigned by the InputStateRegistry of the Mechanism to which the InputState belongs. Note that some Mechanisms automatically create one or more non-default InputStates, that have pre-specified names. However, if any InputStates are specified in the input_states argument of the Mechanism’s constructor, those replace those InputStates (see note), and standard naming conventions apply to the InputStates specified, as well as any that are added to the Mechanism once it is created.

Note

Unlike other PsyNeuLink components, State names are “scoped” within a Mechanism, meaning that States with the same name are permitted in different Mechanisms. However, they are not permitted in the same Mechanism: States within a Mechanism with the same base name are appended an index in the order of their creation.

prefs

PreferenceSet or specification dict – the PreferenceSet for the InputState; 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).