Repository navigation
An integral already being worked out is a cycle, and is declined at once - #1234
Merged
Merged
Conversation
#1233 bounded the integrator's descent, which stopped it killing the process. That was necessary and it was not sufficient: the descent branches, so 32 levels of a cycle is still an enormous search. Measured on Rubi's independent test suites, problems 1400-1450 took 985 seconds under the bound alone where v2.4.0 took 44. One integrand held the run for over ten minutes. Declining at the first repeat instead: 37 seconds over the same fifty problems, which is v2.4.0's figure and slightly under it. The set is keyed on the integrand with its variable renamed to one canonical name, and that renaming is the whole point. SolveBySubstitution names each new variable with Variable.CreateUnique, so a level and the level it came from are alpha-equivalent rather than equal. A set keyed on the integrand as written would never see the same entry twice -- which is exactly why the memo added in #1157 could not stop this either, and why the first fix had to be a depth bound rather than a visited set. DeepestDescent stays as a backstop for anything this does not model, rather than as the mechanism. #1232 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura
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.
Follows #1233, same issue #1232.
#1233 bounded the descent, which stopped the integrator killing the process. That was necessary and it was not sufficient. The descent branches, so 32 levels of a cycle is still an enormous search.
Measured on Rubi's independent test suites, problems 1400–1450:
v2.4.0The renaming is the whole point
The set is keyed on the integrand with its variable renamed to one canonical name.
SolveBySubstitutionnames each new variable withVariable.CreateUnique, so a level and the level it came from are alpha-equivalent rather than equal. A set keyed on the integrand as written would never see the same entry twice — which is exactly why the memo added in #1157 could not stop this, and why the first fix had to be a depth bound rather than a visited set.DeepestDescentstays, as a backstop for anything this does not model rather than as the mechanism.Checked
Full suite green: 8499 and 1485. The Calculus chunk, which holds the integration tests, is 1 m 07 s against 1 m 13 s before this change, so the per-call rename is not costing anything measurable where it is most exercised.
🤖 Generated with Claude Code
https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura