Stop reading an indeterminate power form off as its value (#754)

[Rafael-SOWNet]

Fixes the first half of #754 — the wrong answer. The corpus miss (its second half) needs Stirling's expansion of ln(x!) and is left for its own PR, as the issue itself proposes.

What was wrong

Where nothing else had a reading of a limit, it was answered by substituting the destination and evaluating. That is right wherever the expression is continuous there, and an indeterminate form is exactly where it is not.

Almost all of them already declined without any help, because they evaluate to NaN and every caller reads NaN as "no limit": 0 * oo, oo - oo, oo / oo, 0^0. The two that do not are oo^0 and 1^oo, which this library's arithmetic answers with 1 — so a limit that assembled either read that 1 off as its answer:

lim x->+oo (e^x) ^ (1/ln(x))    was  1     is  +oo
lim x->+oo (x^2) ^ (1/ln(x))    was  1     is  e^2
lim x->+oo (x!)  ^ (1/x)        was  1     is  unevaluated   (it is +oo)
lim x->+oo (x!)  ^ (1/ln(x))    was  1     is  unevaluated   (it is +oo)

(x^2)^(1/ln x) is e^(2*ln(x)/ln(x)), that is e^2 at every x, so the old answer was not merely imprecise. (x!)^(1/x) grows like x/e — (100!)^(1/100) is already 37.99. Both checked numerically at up to x = 1e9 rather than argued.

Where it is guarded

The two places that assemble such a form:

• LimitSolvers.SolveBySubstitution, which puts the destination into the whole expression — this is where (x!)^(1/x) became (+oo)!^(1/(+oo));
• the Powf descent in Limit.Classes.cs, which puts each part's own limit in place of the part. The sum, the product and the quotient are already guarded there by IsDeterminate; the power was not.

Both were needed — fixing only the first left the descent to reassemble (+oo)!^0 for itself.

What it deliberately does not do

It does not change what (+oo)^0 or 1^oo evaluate to. Both are still 1, the same convention SymPy and IEEE 754's pow use. The change is that a limit no longer reads its answer off one. #738's evaluation half is untouched.

0^0 is deliberately not guarded. Its NaN is how the library says lim x->0 x^x does not exist — x^x is not real to the left of 0 — and LimitTest.TestNoLimit pins it. Including 0^0 broke exactly those three tests, which is what located the distinction: the guard is for indeterminate forms the arithmetic answers with a value, not for the ones it already answers with NaN.

What it costs

Three limits answered 1 are now unevaluated:

lim x->+oo (x!)  ^ (1/x^2)      was  1     is  unevaluated   (it is 1)
lim x->0   (1/x) ^ x            was  1     is  unevaluated
lim x->0   (1/x) ^ (x^2)        was  1     is  unevaluated

The first was right by luck: the same substitution gave 1 for (x!)^(1/x), where the answer is +oo, and the two cannot be told apart at the point where the value is read off. Answering it properly wants the Stirling expansion — #754's second half — and it is pinned here so that work has a target.

The other two are two-sided limits at 0 whose base has no two-sided limit at all and which are not real to the left of 0, so the 1 came from the complex continuation. Their one-sided readings are unchanged: lim x->0+ (1/x)^x is still 1, lim x->0+ (1/x)^(1/ln x) is still 1/e.

Recorded in BREAKING-CHANGES.md.

Measured

225 generated powers at 0 and +oo — bases including x!, 1+1/x, e^x, ln(x), (x+1)/(x+2), exponents including 1/x, 1/x^2, 1/ln(x), x, x^2 — diffed against master:

	count
a wrong value → the right value	2
a wrong value → unevaluated	3
NaN → unevaluated	1
a right value → unevaluated	3 (the costs above)

Suites and harnesses, from a clean build of this branch:

• unit tests 5225 passed, 0 failed (5201 on master; 24 added here, 7 of which fail without the guards)
• F# wrapper tests 130 passed
• casbench 112/117 solved, 0 wrong, 0 error, 0 timeout — unchanged
• propcheck 0 failures of 1337 checks
• rootcheck 596/596 clean
• simpsweep 0 disagreements of 10463

[Rafael-SOWNet]

One thing worth flagging for review, since the measurement does not show it.

The 1^oo half of the guard changed nothing in the 225-expression sweep. Every one of the ten differences was an oo^0 form. That is expected rather than surprising: #739 made the second remarkable limit re-read an expression after simplification, so a 1^oo is caught by the rule that reads one before the substitution is ever reached.

It is included anyway because it is the same defect — an indeterminate form whose arithmetic gives 1 rather than NaN — and leaving half of it in place would mean the guard stops being true the moment the second remarkable limit fails to fire for some shape nobody has tried yet. What the tests pin is that it costs nothing today: (1 + 1/x)^x, (x - 5)^x / x^x, ((x+1)/(x+2))^x and (1 - 1/x^2)^(x^2) are all 1^oo forms and all still answer, in ThePowersThatWereAlreadyRightAreUndisturbed.

If you would rather this PR stayed strictly to the oo^0 case that #754 reports, dropping the second line of IsIndeterminatePowerForm does exactly that and no test changes.