Checker¶
The checker is the deterministic verifier of the pipeline. Implement
Checker.check to return
Passed or Failed for a
(data, solution) pair. The
CheckerOrchestrator runs a pool of checker
instances concurrently and is managed by the runner — you normally only
implement Checker and hand the framework a CheckerFactory.
checker ¶
CheckerFactory ¶
CheckerFactory = Callable[[], Checker[DataT, SolutionT]]
Zero-argument callable that returns a fresh Checker. Called once per
checker worker so each worker gets its own instance; a Checker subclass whose
constructor takes no arguments is itself a valid factory.
Checker ¶
Bases: ABC
Deterministic verifier of the pipeline. Subclass it and implement
check for your benchmark; the framework runs a pool of instances
concurrently via a CheckerFactory and a CheckerOrchestrator.
The type parameters are the data-item schema (DataT, a DataModel
subclass) and the parsed solution type produced by your SolutionAdapter.
check
abstractmethod
¶
check(data: DataT, solution: SolutionT) -> CheckResult
Verify solution against the problem instance data.
| Parameters: |
|
|---|
| Returns: |
|
|---|
Failed
dataclass
¶
Outcome of a check the solution did not satisfy. Return this from
Checker.check when the solution is wrong.
reason
instance-attribute
¶
Short, human-readable explanation of the failure. The visualizer groups attempts into failure classes by this string, so keep it stable and low-cardinality (a category, not a per-attempt message).
runtime
class-attribute
instance-attribute
¶
Wall-clock time the check took, if measured. Surfaced in the run summary.
metadata
class-attribute
instance-attribute
¶
Arbitrary extra data to attach to the result; persisted with the output.
Passed
dataclass
¶
Outcome of a check the solution satisfied. Return this from
Checker.check when the solution is correct.
CheckerOrchestrator ¶
CheckerOrchestrator(checker_factory: CheckerFactory[DataT, SolutionT], checker_workers: int, tracker: WorkerStatusTracker, retry_timeout: int = 10)
Runs a fixed pool of Checker instances concurrently on behalf of the
runner. You normally do not construct this yourself — the Runner builds it
from your CheckerFactory — but it is the bridge between solver workers and
your checkers.
A thread pool of checker_workers threads is created, each leasing one
Checker from a carousel, so a given checker instance only ever runs one
check at a time.
Build the pool.
| Parameters: |
|
|---|
check ¶
check(data: DataT, solution: SolutionT, solver_id: int) -> CheckResult
Check one (data, solution) pair on the pool and return the result.
Blocks until a checker worker produces a result, polling on an internal timeout so the call can be interrupted when the run is shutting down.
| Parameters: |
|
|---|
| Returns: |
|
|---|
| Raises: |
|
|---|
stop ¶
Signal shutdown and cancel pending checks. Afterwards check raises
InterruptedError and in-flight futures are cancelled.