Previous value of TransferMechanism is initialized as NoneType?

[jongkeesbj]

The purpose of the dummy code below is for task_mech to wait with executing until iti_mech has executed 3 times (simply integrating an input of zero). However, an error message seems to indicate that the previous value of iti_mech is initialized as None which leads to the following error:

File "C:\PsyNeuLink\psyneulink\core\components\functions\nonstateful\objectivefunctions.py", line 1180, in _function
result = np.max(np.fabs(v1 - v2))

TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

import psyneulink as pnl

iti_mech = pnl.TransferMechanism(
    integrator_mode=True,
    integration_rate=1,
    termination_threshold=3,
    execute_until_finished=False
)

task_mech = pnl.ProcessingMechanism(input_shapes=1)

comp = pnl.Composition()
comp.add_nodes([iti_mech, task_mech])

comp.scheduler.add_condition(
    task_mech, pnl.WhenFinished(iti_mech)
)

inputs = {
    iti_mech: [0],
    task_mech: [1]
}

comp.run(inputs)

[jongkeesbj]

I forgot to specify termination_measure=pnl.TimeScale.TRIAL on iti_mech, which resolves the issue. But I still don't understand why the error occurs for the default setting of termination_measure. Would appreciate any insight on that!

[kmantel]

When termination_measure isn't set, the default behavior for WhenFinished/Mechanism.is_finished is to get the difference between the current and previous values of the mechanism's value Parameter (said this way to emphasize it's not the value of its previous_value Parameter. This is a confusion that's been on the backlog to fix) and checks it against termination_threshold using termination_comparison_op.
The problem in this case is ours, not the user's. The None value causing your exception is happening when the value Parameter doesn't have a previous value yet, and this isn't accounted for. I think in general this kind of termination is also possibly not functioning correctly right now for a few other reasons.

Setting termination_measure to a TimeScale bypasses this problem because it ignores the mechanism's value and compares its number of executions against termination_threshold in the specified TimeScale.

Is it working the way you expect now after your change?

[jongkeesbj]

Thank you Katherine, that makes sense. I almost always use TimeScale so I hadn't encountered this before. If it wouldn't be too much effort, it would be great to fix this soon. Dawa is currently working on TransferMechanisms and LCAMechanisms where the default setting for termination_measure should probably be used.