System.eval accepts any point precision; mixed time/space precisions throw (closes #377) - #387
Open
ofloveandhate wants to merge 1 commit into
Open
Conversation
…isions throw Closes bertiniteam#377. System evaluation is stateless (blocks are value-in, the SLP is the evaluator), so the INPUT defines the working precision: SetVariables now changes the system's internal precision to match the incoming point instead of throwing on mismatch. Callers evaluating at precision p get the evaluation at precision p; the system's previous precision is not their concern. Precision-managing callers (the trackers) always match already and take the fast path unchanged. The time-and-variables case is different in kind: both are supplied in the SAME call, so a precision mismatch between them is caller incoherence, not internal-state drift -- silently promoting either one would guess intent and mask exactly the ambient-precision-drift bugs this exposes. EvalInPlace and JacobianInPlace (the funnels for every point+time evaluation) throw with a message naming both precisions and instructing the caller to align them. Previously SetPathVariable checked nothing at all, so mixed time slipped in silently. Tests: C++ (system_evaluate_mpfr_any_point_precision -- the system follows the input up to 50 and down to 20 digits, values and result precisions checked; system_evaluate_mixed_time_precision_throws) and Python (the eval surface accepts any precision; the mismatch message reaches Python naming both precisions and the word 'align'). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #377.
The footgun
System::SetVariablesthrew whenever a multiprecision point's precision differed from the system's internal precision. Since the ambient default precision drifts (most notably after an adaptive-precision solve), every consumer ofSystem::Evaleventually hitat a call site that did nothing wrong. The cellular/NID layers had grown repeated align-then-eval workarounds; each new eval call site re-discovered the crash.
The contract now
Evaluation is stateless (blocks are value-in; the SLP is the evaluator), so the input defines the working precision:
SetVariableschanges the system's internal precision to match the incoming point — in both directions. A caller evaluating at precision p gets the evaluation at precision p; the system's previous precision is not their concern. Precision-managing callers (the trackers) always match already and take the fast path unchanged.EvalInPlace/JacobianInPlace(the funnels for every point+time evaluation) now throw with a message naming both precisions and instructing the caller to align them. PreviouslySetPathVariablechecked nothing, so mixed time slipped in silently.BERTINI_DISABLE_PRECISION_CHECKSbuilds behave as before (no checks, no alignment).Tests
test_classes):system_evaluate_mpfr_any_point_precision— a precision-30 system follows a 50-digit point up (result precision 50, values exact) and a 20-digit point down; Jacobian too.system_evaluate_mixed_time_precision_throws— mismatched time throws for bothEvalandJacobianInPlace; aligned inputs evaluate at their common precision.python/test/classes/system_test.py): the eval surface accepts any point precision, and the mixed time/space message reaches Python as aRuntimeErrornaming both precisions and the word "align".Both doc-lint passes clean (C++ and Python).
🤖 Generated with Claude Code