this is a different type of operator that is updated every cycle (or N cycles) automatically, and reacts to its concepts current goal truth (and possible relation to belief truth). rather than wait for an execution opportunity, the update function is invoked whether goal truth is positive or negative, or otherwise (missing etc). each cycle results in an optional feedback belief allowing the motor to report its resulting state, which may not necessarily match the goal provided to it.
they range from simple pushbuttons to latching pushbuttons, bipolar "differential" concept pairs, bipolar mutex pushbuttons, n-ary switches, etc. they are meant to adapt to different kinds of real-time environment motors and the signals / conventions / protocols that best fit their control. there are subtle second order parameters like debouncing, latching, and resolving conflict amongst mutex sibling concepts.
the ordinary operator execution mechanism might be able to emulate the above cases but i doubted its reliability for per-cycle updates. operators/operations are fine for asynch events and can certainly be used in other subsystems.
this is a different type of operator that is updated every cycle (or N cycles) automatically, and reacts to its concepts current goal truth (and possible relation to belief truth). rather than wait for an execution opportunity, the update function is invoked whether goal truth is positive or negative, or otherwise (missing etc). each cycle results in an optional feedback belief allowing the motor to report its resulting state, which may not necessarily match the goal provided to it.
ive implemented many different kinds of motor / actuators here: https://github.com/automenta/narchy/blob/volatile1/app/src/main/java/nars/agent/NAct.java
they range from simple pushbuttons to latching pushbuttons, bipolar "differential" concept pairs, bipolar mutex pushbuttons, n-ary switches, etc. they are meant to adapt to different kinds of real-time environment motors and the signals / conventions / protocols that best fit their control. there are subtle second order parameters like debouncing, latching, and resolving conflict amongst mutex sibling concepts.
the ordinary operator execution mechanism might be able to emulate the above cases but i doubted its reliability for per-cycle updates. operators/operations are fine for asynch events and can certainly be used in other subsystems.