Monty's FeatureGraphMemory: the same library, read by feature.

The feature-at-location module matches an observation in two questions. Which nodes could I be standing on — that is this module's match_all_node_features — and, once a pose is being tested, does the pose agree. The first question is what narrows a graph of twenty thousand nodes to the handful worth walking from, so it is asked of the whole graph at once.

Why this is a module of functions and not a second struct

Monty spells the difference as a subclass, and the difference is four functions: hypotheses with poses in them, a node's frame, the matching nodes, and the comparison behind them. Everything else — the models, the feature rows, the learning — is GraphMemory's, and a second struct would be the same fields with a different name. So new/1 builds a GraphMemory and these functions read it, which is the same shape Monty.Frameworks.Models.GraphMatching.GraphMemory already has for the evidence module's EvidenceGraphMemory.

The comparison

Monty builds two arrays per column — the observed value plus and minus its tolerance — and asks numpy whether each node's value lies between them. A feature that is circular (hue, the first of hsv's three) wraps through 1, so a tolerance of 0.1 around 0.05 covers [0.95, 1] and [0, 0.15] and the test becomes "outside" rather than "inside". A node with no stored value has no evidence for that column and does not match, which is what Monty's NaN pre-fill does.

Where the tolerances come from

Monty's memory holds features_to_use and the tolerances, because in Python the module assigns its own tolerances to it. This port's memory holds the feature names it keeps rows for, which is what the evidence kernel reads, so the tolerances are passed in by the learning module that owns them — the same numbers, in the same place as the config that stated them.