inconsistency in simplify_radical

[wdjoyner]

This is a problem:

sage: f = sqrt(25-x)*sqrt(1+1/(4*(25-x)))
sage: f.integral(x,9,16)
integrate(sqrt(1/(4*(25 - x)) + 1)*sqrt(25 - x), x, 9, 16)
sage: f.nintegral(x,9,16)
(24.9153783348643, 2.7661626694613149e-13, 21, 0)
sage: g = f.simplify_radical()
sage: g.integral(x,9,16)
I*(65*sqrt(65)*I/6 - 37*sqrt(37)*I/6)/2
sage: ans = g.integral(x,9,16)
sage: ans.real()
(37*sqrt(37)/6 - 65*sqrt(65)/6)/2
sage: RR(ans.real())
-24.9153783348643

CC: @burcin @aghitza @orlitzky

Component: symbolics

Reviewer: Michael Orlitzky, Karl-Dieter Crisman

Issue created by migration from https://trac.sagemath.org/ticket/3520

[haraldschilly]

comment:1

Just for reference, the same with MMA6:

In[3]:=
f[x_] := Sqrt[25 - x]*Sqrt[1 + 1/(4*(25 - x))]

In[16]:=
g[x_] := Integrate[f[x], x]; FullSimplify[g[x]]

Out[16]=
(-(1/12))*(4 + 1/(25 - x))^(3/2)*(25 - x)^(3/2)

In[15]:=
FullSimplify[D[g[x], x] - f[x]]

Out[15]=
0

In[6]:=
Integrate[f[x], {x, 9, 16}]

Out[6]=
(1/12)*(-37*Sqrt[37] + 65*Sqrt[65])

In[8]:=
NIntegrate[f[x], {x, 9, 16}, WorkingPrecision -> 40]

Out[8]=
24.915378334864299909236795241439053518882655529789`40.

[kcrisman]

comment:2

With the new symbolics and Maxima 5.19.1:

sage: sqrt(25-x)*sqrt(1+1/(4*(25-x)))
sqrt(-1/4/(x - 25) + 1)*sqrt(-x + 25)
sage: f = _
sage: f.integral(x)
1/12*(4*I*x - 101*I)*sqrt(4*x - 101)
sage: f.integral(x,9,16)
-37/12*sqrt(37) + 65/12*sqrt(65)
sage: f.nintegral(x,9,16)
(24.9153783348643, 2.7661626694613149e-13, 21, 0)
sage: g = f.simplify_radical()
sage: g.integral(x,9,16)
37/12*sqrt(37) - 65/12*sqrt(65)
sage: ans = g.integral(x,9,16)
sage: ans.real()
37/12*sqrt(37) - 65/12*sqrt(65)
sage: RR(ans.real())
-24.9153783348643

Maxima can now integrate the original one, but still gives the wrong simplification (?) of f. It seems to be choosing the wrong square root of negative one, as it were, since

sage: j = -g
sage: j.integrate(x,9,16)
-37/12*sqrt(37) + 65/12*sqrt(65)

So the real problem is in simplify_radical().

[kcrisman]

comment:4

One may want to check the latest CVS of Maxima, where I believe some definitions relating to this have changed.

[kcrisman]

comment:5

Just updating. This is still in 5.20.1, but it's not clear whether this is really a bug, since radical simplifications will in their nature sometimes change which square root of -1 they use, and perhaps it's not possible to do so consistently across multiplication or division. Comments?

[kcrisman]

comment:6

Maxima devs have been discussing some things related to this, so it could be worth checking whether this has changed again in their CVS.

[kcrisman]

comment:7

What is really going on here is that simplify_radical uses radcan under the hood, which treats things as symbolic expressions, not functions, and just chooses a branch - consistently, but arbitrarily. At least I think that is what is here. See the Maxima list thread starting here.

[kcrisman]

comment:12

It seems to be that this is probably a dup of #14305, #11912, and/or other such tickets. Thoughts?

[orlitzky]

comment:13

Replying to @kcrisman:

It seems to be that this is probably a dup of #14305, #11912, and/or other such tickets. Thoughts?

Indeed, #11912 "fixes" it by renaming simplify_radical and updating its documentation so that it's very clear that this might happen.

[kcrisman]

comment:14

It seems to be that this is probably a dup of #14305, #11912, and/or other such tickets. Thoughts?

Indeed, #11912 "fixes" it by renaming simplify_radical and updating its documentation so that it's very clear that this might happen.

In which case perhaps this integration example could be added there.

[orlitzky]

comment:15

Replying to @kcrisman:

In which case perhaps this integration example could be added there.

There are a lot of examples of problems with simplify_radical, but this one isn't particularly clear. It's not like someone is going to see the example in the description and go "oh, that affects me!"

I think this ultimately comes down to sqrt(x^2) anyway, and that is included as an example.

That was my reasoning anyway. If it will help get it reviewed faster, I'll add whatever you want =)

[kcrisman]

comment:16

In which case perhaps this integration example could be added there.

That was my reasoning anyway. If it will help get it reviewed faster, I'll add whatever you want =)

Well, I think that pointing out that things you might not think would be affected is not bad.

[orlitzky]

comment:17

Ok, I've just added this example to the branch at #11912.

[kcrisman]

comment:18

Ok, I've just added this example to the branch at #11912.

Sweet.

[kcrisman]

Reviewer: Michael Orlitzky, Karl-Dieter Crisman