Monty. Frameworks. Models. MotorPolicySelectors. MotorPolicySelector behaviour
(ExTbpMonty.Core v0.1.0)
Copy Markdown
View Source
The motor system's question to a selector: given this step, what should move?
Mirrors tbp/monty/frameworks/models/motor_policy_selectors.py::MotorPolicySelector,
which joins Monty's runtime interface and its experiment interface into one.
A selector decides which policy acts — one policy always, or one of several
depending on the goals that arrived — and answers the same
MotorPolicyResult whatever it chose.
Two differences from Monty, both forced by values rather than pointers:
- the selector is handed back along with the result, because choosing is also recording — Monty appends the chosen goal to itself — and a struct cannot be changed in place;
- there is no
fixme_provide_motor_system. Monty hands the selector the motor system only so the chosen policy can setmotor_only_stepon it; here that flag travels in the result, so the call and its name both go.
Summary
Callbacks
The actions to take this step, whether learning modules should sit it out, and the selector as it now stands.
Forgets everything the selector knows about the episode so far.
What the selector recorded, for a run that wants to be read afterwards.
Types
@type t() :: struct()
Callbacks
@callback call( t(), ctx :: Monty.Context.t(), observations :: map() | nil, state :: Monty.Frameworks.Models.MotorSystemState.t(), percept :: Monty.Cmp.Message.t() | nil, goals :: [Monty.Cmp.Goal.t()] ) :: {Monty.Frameworks.Models.MotorPolicies.MotorPolicyResult.t(), t()}
The actions to take this step, whether learning modules should sit it out, and the selector as it now stands.
Forgets everything the selector knows about the episode so far.
What the selector recorded, for a run that wants to be read afterwards.