Repository navigation
(a + b arcsin(c x))/sqrt(d - c^2 d x^2) integrates to NaN with downcasting off #1490
Description
Activity
Narrowed down on master (
856831cf): theNaNneeds the integrand to be parsed with downcasting on and integrated with it off. The setting at parse time matters as much as the setting at integration time:parsed integrated (a + b arcsin(c x))/sqrt(d - c^2 d x^2)1/sqrt(2 - 2x^2)on on the antiderivative -arcsin(-x) sqrt(2)/2on off NaN + Cthe antiderivative, with 2^(1/2)off on the antiderivative, a different form left unevaluated off off left unevaluated left unevaluated A string parsed with downcasting off loses even
1/sqrt(2 - 2x^2), whatever the setting when it's integrated. So the parser reads the setting too, which I haven't bisected yet. It bears on removingDowncastingEnabledin v3, since the parse reads it as well as the evaluation. The parser also caches by string, so a string parsed once under one setting comes back under the other with the first parse's numbers.Bisected on master. There are two causes.
The
NaNis the zero test.TreeAnalyzer.IsZeroise.Evaled is Complex c && c == 0. With downcasting off, the literal0converts toComplex(0, 0), which doesn't equalInteger 0orReal 0, so nothing is zero under that setting. For1/(1 + c^2 x^2),IntegrateRationalQuadraticthen keeps itsa = 0case,1 * ln(0 * x + 1) / 0, and the piecewise collapses toNaN + C. Limits returnNaNtoo:limit(sin(c x)/x, x, 0)andlimit((1 - cos(c x))/x^2, x, 0). I haven't traced those.The parse. With downcasting off, an integer literal is a decimal
Real, sox^2isn't a whole power to the integrator."0","1"and"-1"are alreadyIntegerwhatever the setting, from a shortcut inFromString. The parse cache is split byExplicitParsingOnlybut not byDowncastingEnabled.A zero test that compares values fixes the
NaN, but not the underlying problem. The rules test numbers by type and against literals, and under decimals those tests fail, so4/1stays4/1. With only the zero test fixed,(d - c^2 d x^2)^(3/2) (a + b arcsin(c x))still gives up, but after 290 s instead of 7.My proposal is that integration and limits compute with downcasting on whatever the caller's setting, and convert the input's decimals to the exact rationals they are on the way in. The answer is then the default setting's answer, and doesn't depend on the setting. The cost is that downcasting off gives
x^2/20rather than0.05 x^2for0.1 x. The alternative is to keep the setting's decimals and leave these unevaluated rather than wrong. Which would you prefer?This is further justification on downcasting's poorly defined semantics and v3 removal. Just do whatever you think is appropriate for v2.
#1516. The cost is the one on the table: with the setting off, decimals come back as the rationals they hold.
- added a commit that references this issue
on Sep 27, 2026 - added a commit that references this issue
on Sep 27, 2026
On master (
fa542e09), withMathS.Settings.DowncastingEnabledoff:With the default setting the answer is
(b arcsin(c x)^2/2 + a arcsin(c x))/(sqrt(d) c) + C, which is right.NaNsays the antiderivative doesn't exist, so this is a wrong answer, not a missing one. 2.5.0 leaves it unevaluated with the default setting. I haven't checked 2.5.0 with downcasting off.Two neighbours from Rubi's 5.1.4 are answered with downcasting on and come back unevaluated with it off:
Not bisected yet. Found while checking #1489, which leaves all three as they are.