## #2590 rpart bug for sqrt expression

None
closed
nobody
None
5
2013-07-02
2013-06-10
No

I believe that ir2 is correct and ir1 is wrong:

```(%i1) i : sqrt(-%e^(%i*x));
(%o1) sqrt(-%e^(%i*x))

(%i2) ir1 : realpart(i);
(%o2) cos((atan2(sin(x),cos(x))+%pi)/2)

(%i3) ir2 : realpart(demoivre(i));
(%o3) (sin(x)^2+cos(x)^2)^(1/4)*cos(atan2(sin(x),-cos(x))/2)

(%i4) subst(x=%pi/4,[ir1,ir2]);
(%o4) [cos((5*%pi)/8),cos((3*%pi)/8)]

(%i5) float(%);
(%o5) [-0.38268343236509,0.38268343236509]
```

## Discussion

• Rupert Swarbrick - 2013-07-02

Hmm. I think that ir1 is actually correct and the other two are wrong! Indeed, `subst(%pi/4, x, i)` gives `sqrt(-%i/sqrt(2) - 1/sqrt(2))`, which I agree with. The argument of this number is half of %pi + %pi/4 and thus is 5/8*%pi and the real part should be negative. (I spent ten minutes staring at Argand diagrams until I was really really convinced).

Now, demoivre(i) gives `sqrt(- %i sin(x) - cos(x))`, which I also believe to be correct. So there's some error in `realpart(sqrt(...))` in this case (which I haven't found yet).

• Rupert Swarbrick - 2013-07-02

Ah, right, now I understand. I think that this is not a bug:

realpart and imagpart are both computed using risplit, which is basically rectform(), so working out what's going on is easier if you use rectform. Then you see the following:

```(%i6) rectform(i);
atan2(sin(x), cos(x)) + %pi        atan2(sin(x), cos(x)) + %pi
(%o6) %i sin(---------------------------) + cos(---------------------------)
2                                  2
(%i7) rectform(demoivre(i));
2         2    1/4     atan2(sin(x), - cos(x))
(%o7) (sin (x) + cos (x))    cos(-----------------------)
2
2         2    1/4     atan2(sin(x), - cos(x))
- %i (sin (x) + cos (x))    sin(-----------------------)
2
```

The point is that the two expressions differ by a factor of -1, but that's fine because they are just taking two different square roots. When it can calculate the sign of the imaginary part of the base, the code in rectform/risplit always takes the square root with non-negative real part (I've just been staring at it for a LONG time, so know it rather intimately...) In general, without knowing the signs of the various bits, it just punts to a generic formula, which turns out to give a different square root depending on the form it's given.

Digging through the code enough to understand what was going on took me quite a while, and I ended up refactoring the biblically-proportioned `risplit-expt` and then carefully documenting the code that deals with square roots. If you're interested, have a look at [82bdd9] and [ec587f].

Anyway, I'm closing this item since I think it's actually not a bug. If I've got the wrong end of the stick (eminently possible!), please reopen...

#### Related

• Rupert Swarbrick - 2013-07-02
• status: open --> closed

JavaScript is required for this form.

No, thanks