An equation between two powers of numeric bases is answered exactly (#1007) - #1097
Merged
Merged
Conversation
…1007) `3 ^ (x+1) = 2 ^ (x-1)` has the exact root `-ln(6) / ln(3/2)`. The multiplicative solver reached it by dividing one exponent by the other, and for two different integer bases that ratio is `ln(3)/ln(2)` -- irrational -- so `InnerSimplified` settled it to a decimal and everything downstream was numeric. The answer agreed with the exact one to seventeen significant figures and then diverged, which is a `double` promoted to a decimal rather than a number that was computed. Taking logarithms has no such step: `a ^ p = b ^ q` is `p ln a = q ln b` for positive real `a` and `b`, and that is an ordinary equation the analytical solver answers exactly. Tried before the multiplicative solver, because it is the substitution that loses the exactness. Both bases must be **decidably positive reals**, which is what makes `ln` of them real and the step an equivalence rather than a branch choice. Anything else declines and the multiplicative path still gets its turn, so this only ever adds answers -- and it does add one: `5 ^ (2x) - 7 ^ (x+3)` was the empty set and is now `3 * ln(7) / (2 * ln(5) + -ln(7))`. **The zero term is why the first version did not fire**, and a trace found it in one run where reading the code had not: the solver is handed `lhs - rhs - 0`, so a two-power equation arrives with three terms. Terms that evaluate to zero are dropped before counting. The test substitutes each root back rather than comparing printed text, which is what the issue asks for: a decimal right to seventeen figures passes any test that reads the answer and fails the equation. It also asserts that the six equations that were exact before are unchanged, since this branch runs ahead of the one that answers them. Fails 4 of its 13 cases without the change.
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 #1007.
3 ^ (x+1) = 2 ^ (x-1)has the exact root-ln(6) / ln(3/2)."3^(x+1) - 2^(x-1)".SolveEquation("x"){ ln(0.04674569822628630438865471319331845734268426895141… ^ (1 / ln(2))) }{ -(ln(3) + ln(2)) / (ln(3) + -ln(2)) }"3^(x+1) - 2^x".SolveEquation("x"){ -ln(3) / (ln(3) + -ln(2)) }"5^(2x) - 7^(x+3)".SolveEquation("x"){ }— no answer at all{ 3 * ln(7) / (2 * ln(5) + -ln(7)) }"3^x - 2^x","2^(2x) - 5·2^x + 4","ln(x)² - 3ln(x) + 2", …Why the decimal appeared
The multiplicative solver divides one exponent by the other. For two different integer bases that
ratio is
ln(3)/ln(2)— irrational — soInnerSimplifiedsettles it to a decimal and everythingdownstream is numeric. The answer then agrees with the exact one to seventeen significant figures
and diverges, which is the signature of a
doublepromoted to a decimal rather than a number thatwas computed.
Taking logarithms has no such step:
a ^ p = b ^ qisp ln a = q ln b, an ordinary equation theanalytical solver answers exactly. It is tried before the multiplicative solver, because that
is where the exactness is lost.
Both bases must be decidably positive reals — that is what makes
lnof them real and thestep an equivalence rather than a branch choice. Anything else declines and the multiplicative
path still gets its turn, so this only ever adds answers.
Two notes on getting there
A trace found in one run what reading the code had not. The first version did not fire at all:
the solver is handed
lhs - rhs - 0, so a two-power equation arrives with three terms and thecount guard rejected it. Terms evaluating to zero are dropped before counting.
The test substitutes each root back rather than comparing printed text, as the issue asks — a
decimal right to seventeen figures passes any test that reads the answer and fails the equation.
It also pins that the six equations exact before are unchanged, since this branch runs ahead of
the one that answers them.
Fails 4 of its 13 cases without the change. Full suite: 8775 passed, 0 failed.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Bjumi5K7fg8yx6UK1mZTQd