# `Monty.Frameworks.Models.NoResetEvidenceMatching.MontyForNoResetEvidenceGraphMatching`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/frameworks/models/no_reset_evidence_matching/monty_for_no_reset_evidence_graph_matching.ex#L1)

The model an unsupervised-inference run starts: one that is never told an
episode has ended.

Mirrors `frameworks/models/no_reset_evidence_matching.py::MontyForNoResetEvidenceGraphMatching`.
Monty's ordinary model begins an episode by resetting its modules, which
throws away their hypotheses and the evidence behind them; this one begins an
episode by resetting the *counters* — the step counts, the terminal states, the
motor system's place in its policy — and empties the buffers. What the modules
believe survives, because in the experiment this class was written for the
object under the sensor changes with no signal announcing it, and the model
has to discover the change from evidence falling away. It is intended for
evaluation-only runs against a pretrained model, with Monty in the matching
phase throughout.

## What a run of this class keeps, and what it forgets

Kept across an object change: the hypothesis space of every module, the
evidence of each hypothesis, the most likely hypothesis, the goal generator's
schedule, each sensor's delta-filter memory, the record of what each sensor was
on at every step (`stepwise_targets_list`), and where the sensor was — which is
why `NoResetEvidenceGraphLM` remembers that itself.

Forgotten: the step counters, the modules' conclusions and the objects and
poses they named, each module's buffer of observations, each sensor's processed
observations, and the model's `done?`.

## One difference from Monty, on purpose

Monty's class resets *fully* once and skips the full reset afterwards, because
some of its modules' fields are only initialised by `reset()` and graphs are
loaded after construction (`__init__`'s comment says so). Neither is true here:
`EvidenceGraphLM.new/2` ends in `reset_stm/1`, and a learning module is built
with the memory it will match against, so a module is fully initialised before
the first episode. The distinction therefore has no work to do, and every
reset is the partial one — which is also what Monty's first reset amounts to on
a module that is already initialised.

## What is not carried

Monty's `snapshot/0` and `restore/1` copy the model's `state_dict` so a run can
be forked and compared. This port has no `state_dict` for a model — the modules
are processes and the memory they hold travels as a `GraphMemory` — so there is
nothing here to copy; `docs/training.md` says where a learned memory is written
instead.

# `child_spec`

```elixir
@spec child_spec(map()) :: Supervisor.child_spec()
```

The model as something a supervisor can start.

Monty's constructor builds the model; here it is `spec` — what the config
resolved to — and starting it is the runtime's.

# `done?`

```elixir
@spec done?(atom() | String.t()) :: boolean()
```

Whether the model has concluded this episode.

# `fixme_set_ground_truth`

```elixir
@spec fixme_set_ground_truth(atom() | String.t(), map() | nil, keyword()) :: :ok
```

`MontyForGraphMatching.fixme_set_ground_truth`: what this episode is about.

# `reset_episode`

```elixir
@spec reset_episode(atom() | String.t()) :: :ok
```

Clears short-term memory for a new episode, as this class defines it.

# `reset_episode_state`

```elixir
@spec reset_episode_state(Monty.Runtime.Step.State.t()) ::
  Monty.Runtime.Step.State.t()
```

`reset/0`, as this class means it: the episode starts again, what the modules
believe does not.

Monty's `_reset_terminal_states` (`lm.set_individual_ts(None)`) and
`_reset_modules_buffers` (`lm.buffer.reset()`, `sm.processed_obs = []`), after
`reset_episode_steps()` and `switch_to_matching_step()`. The motor system is
deliberately not reset: Monty's override does not reset it either, and a policy
that forgot its last action would have to find the object again after every
object change.

# `set_experiment_mode`

```elixir
@spec set_experiment_mode(
  atom() | String.t(),
  Monty.Frameworks.Models.AbstractMontyClasses.LearningModule.mode()
) :: :ok
```

`MontyBase.set_experiment_mode`: whether this episode trains or evaluates.

# `set_ground_truth_state`

```elixir
@spec set_ground_truth_state(Monty.Runtime.Step.State.t(), map() | nil, keyword()) ::
  Monty.Runtime.Step.State.t()
```

`fixme_set_ground_truth`: the object this episode is about, told to the modules
without emptying their record of what the sensor was on.

Monty's override writes `lm.primary_target` and `lm.primary_target_rotation_quat`
itself instead of calling `lm.fixme_reset_ground_truth`, which would clear
`stepwise_targets_list` — the only record of which object the sensor was on at
every step of a run that never restarts.

# `state`

```elixir
@spec state(atom() | String.t()) :: Monty.Runtime.Step.State.t()
```

The coordinator's state, which is where an episode's conclusion lives.

# `status`

```elixir
@spec status(atom() | String.t()) :: Monty.Experiment.RecognitionStrategy.model()
```

The four things a recognition policy may read off the model.

# `step`

```elixir
@spec step(atom() | String.t(), map(), map(), Monty.Context.t()) ::
  {:ok, [map()], map()}
```

One timestep: what the modules were given and what they made of it.

# `stop`

```elixir
@spec stop(atom() | String.t()) :: :ok | {:error, :not_found}
```

Stops the model's processes.

# `supervise`

```elixir
@spec supervise(atom() | String.t(), map(), [number()], [String.t()]) :: :ok
```

`MontySupervisedObjectPretrainingExperiment._pass_target_info_to_model`.

# `switch_to_exploratory_step`

```elixir
@spec switch_to_exploratory_step(atom() | String.t()) :: :ok
```

`Monty.switch_to_exploratory_step`: what a recognition policy can ask for.

# `time_out`

```elixir
@spec time_out(atom() | String.t()) :: :ok
```

`Monty.time_out_lms`: what a recognition policy can ask for instead of stopping.

# `update_ltm`

```elixir
@spec update_ltm(atom() | String.t()) :: :ok
```

`MontyBase.update_ltm`: write the episode into long-term memory.

---

*Consult [api-reference.md](api-reference.md) for complete listing*