Repository navigation
Fix repeated rejected steps at large floating-point times - #786
Open
AHMETHAKANBEZIR1 wants to merge 1 commit into
Open
AHMETHAKANBEZIR1 wants to merge 1 commit into
AHMETHAKANBEZIR1 wants to merge 1 commit into
Conversation
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.
At large float32 times, an adaptive step can be rejected indefinitely even when a smaller representable step is available. For Dopri5 solving
y' = -20*y,t0=1e5,t1=t0+.125,dt0=.03125,y0=1, andPIDController(rtol=0, atol=6e-5), main exhausts 64 steps with no accepted steps. The same autonomous problem near time zero succeeds.The PID factor is less than one, but adding the smaller duration to the large start time rounds back to the rejected endpoint. When
dtminis unset, use Equinox's differentiableprevbeforehelper to move to the preceding representable endpoint, provided it still leaves a positive interval. Accepted steps and explicit minimum-step behavior are unchanged. This does not promise success when no smaller positive interval can be represented.Related to #785. The original Tsit5 example currently succeeds in my environment, so this PR addresses the separately reproduced rounded-rejection case and does not claim to resolve every large-time failure.
Regression coverage checks JIT controller adaptation at positive/negative times and a complete Dopri5 solve in both integration directions against the analytic solution.
Validation (Windows CPU, JAX 0.11.2): all 1002 tests passed in the final full-suite run; the 22 adaptive-controller tests and configured Ruff/pyright/pre-commit hooks also passed. All four new regressions fail on clean upstream e950aa2 with the expected unchanged-endpoint or max_steps failures. No GPU validation claimed.
An earlier full run had 1001 passes and one progress-meter assertion failure (63 carriage returns rather than 62). That constant-step progress test passed in isolation on clean upstream, and all four progress-meter tests passed in isolation on this branch. The complete suite was then rerun without source changes and passed all 1002 tests. The earlier failure is reported here rather than counted as a clean full-suite pass.
AI disclosure: prepared and checked autonomously with OpenAI Codex on behalf of AHMETHAKANBEZIR1. No independent human review is claimed.