Skip to content

feat(records): ZeroDimConfig.recall — force a fresh re-track past the records recall - #308

Merged
ofloveandhate merged 2 commits into
developfrom
feature/force_norecall
Jul 9, 2026
Merged

feat(records): ZeroDimConfig.recall — force a fresh re-track past the records recall#308
ofloveandhate merged 2 commits into
developfrom
feature/force_norecall

Conversation

@ofloveandhate

Copy link
Copy Markdown
Contributor

ZeroDimConfig.recall — force a fresh re-track past the records recall

A recording solve recalls an identical ask (same system + settings + seed) instead of re-tracking
it (ADR-0046) — correct, and usually what you want. But it silently starves anything that needs the
tracking to actually happen:

  • a path-collecting observer (SolutionPathCollector) comes back empty — you attached it, solved,
    and got nothing, with no error;
  • a benchmark measures recall time, not compute time;
  • a re-verification of a recorded run never actually recomputes.

This came up live: a path-portrait observer collected 0 paths on a re-solve, and it took a full
diagnostic pass to realize the paths were recalled, not tracked. Recording working — but confusing.

The fix

Add ZeroDimConfig.recall (default True). Set it False to force a fresh track of every path
even when the paths are recorded; the fresh run is still recorded.

cfg = solver.get_config(ZeroDimConfig)
cfg.recall = False          # re-track even if this exact ask is already recorded
solver.set_config(cfg)

Like num_threads, it's transient — it changes only whether/how the work runs, not what is
computed — so it is deliberately excluded from the config's canonical encoding / identity digest (the
digest is unchanged; no version bump).

(There is a second, seed-based way to dodge recall: seed = 0/None draws fresh entropy each solve, so
the ask is never identical twice. That's the "give me a fresh random run" lever (non-reproducible);
recall=False is the "recompute THIS exact reproducible ask" lever. Different intents — this PR adds
the latter.)

Changes

  • gate RecallRecordedPaths on the flag in the shared solve loop (zero_dim_solve.hpp)
  • exclude recall from CanonicalEncoding(ZeroDimConfig) (mirrors num_threads)
  • expose config.recall in the binding
  • C++ test: recall=false re-tracks an otherwise-recalled ask (NumPathsRecalled()==0, roots still found)
  • Python test: recall=False re-tracks so a SolutionPathCollector collects again

Verification

  • test_nag_algorithms + test_classes green (config-digest fixture unchanged).
  • pytest python/test/zero_dim/ — 121 passed.
  • doclint not run locally (no doxygen in env); the new recall field carries a Doxygen comment.

🤖 Generated with Claude Code

ofloveandhate and others added 2 commits July 8, 2026 19:54
… records recall

A recording solve RECALLS an identical ask (same system + settings + seed) instead of
re-tracking it (ADR-0046). That is correct and usually what you want, but it silently
starves anything that needs the tracking to actually happen -- a path-collecting observer
comes back empty, a benchmark measures recall not compute, a re-verification never runs.

Add `ZeroDimConfig.recall` (default true). Set it false to force a fresh track of every
path even when the paths are recorded; the fresh run is still recorded. Like num_threads it
is transient (it changes only WHETHER the work runs, not WHAT is computed), so it is
deliberately excluded from the config's canonical encoding / identity digest.

- gate RecallRecordedPaths on the flag in the shared solve loop (zero_dim_solve.hpp)
- exclude recall from CanonicalEncoding(ZeroDimConfig) (digest unchanged)
- expose config.recall in the binding
- C++ test: recall=false re-tracks an otherwise-recalled ask (NumPathsRecalled 0, roots still found)
- Python test: recall=False re-tracks so a SolutionPathCollector collects again

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ofloveandhate
ofloveandhate merged commit dbb7b08 into develop Jul 9, 2026
4 of 7 checks passed
ofloveandhate added a commit that referenced this pull request Jul 9, 2026
Bump `VERSION` from `3.1.0.dev1` to **`3.1.0rc1`** — release candidate
for 3.1.0.

`VERSION` is the single source of truth (scikit-build-core reads it
dynamically; `publish.yml`'s
`check_version` asserts a release tag matches it). This one-line change
is docs-adjacent: `VERSION`
is in the workflow `paths-ignore`, so this PR runs **no CI** and needs
no approvals — it can merge
straight in.

3.1.0.dev1 → 3.1.0rc1 gathers the 3.1.0 line so far: the UI
quality-of-life batch (#305, issues
#293#304 + solution group projection), the numpy-compat overhaul
(#306), and `ZeroDimConfig.recall`
(#308).
ofloveandhate added a commit that referenced this pull request Jul 9, 2026
The changelog had drifted badly: the last entry was **2.0.1**, while
**2.0.2**, the entire
**3.0.0** modernization, and the **3.1.0** line had all shipped — with
their notes living only
in commit messages, PRs, and GitHub Releases. This consolidates them
back into `CHANGELOG.md`,
newest-first, in the existing *Keep a Changelog* format.

### New entries
- **[3.1.0] – 2026-07-09** — NumPy interop for the mp dtypes (#306), the
Python UI
quality-of-life batch (#293#304, #305), `ZeroDimConfig.recall` (#308),
prebuilt CI deps
  (ADR-0049, #282), and docs-store Pages (ADR-0050, #291, #292).
- **[3.0.0] – 2026-07-07** — reworked from the hand-written v3.0.0
release notes (~70 PRs; full
  themed index in #238) into Added / Changed / Fixed sections.
- **[2.0.2] – 2026-05-22** — the packaging/CI maintenance entry that was
never recorded.

Older 1.0.x / 2.0.1 entries and the commented template are untouched.

### Why now (load-bearing)
`publish.yml`'s `github-release` job builds the release body from the
**top** `CHANGELOG.md`
block. That block was the stale **[2.0.1]** — so a final `v3.1.0` tag
would have published 2.0.1's
notes as the 3.1.0 release. With this merged, the extraction yields
exactly the **[3.1.0]** block
(verified locally against the workflow's extraction logic).

Docs-only (`**/*.md` → `paths-ignore`), so this runs no CI. **Merge
before tagging `v3.1.0`.**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant