Doctest: Immediate simplifications of symbolic powers

[zimmermann6]

in Sage 5.7 we get:

sage: sqrt(x^2).simplify_radical()           
x

This is wrong (consider x=-1 for example). Even:

sage: assume(x<0)
sage: sqrt(x^2).simplify_radical()
x

Previously it was

sage: sqrt(x^2).simplify_radical()
abs(x)

Note: this invalidates a whole part of our book (in french) about Sage at
http://sagebook.gforge.inria.fr/

Depends on #23325

CC: @orlitzky @burcin @rwst

Component: calculus

Author: Ralf Stephan

Branch/Commit: e5d5ba0

Reviewer: Jeroen Demeyer

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

[kcrisman]

comment:1

Regarding these three tickets (#14305, #14306, #14308 (thanks for the pointer, Paul!)) perhaps it would be good to get that book in the standard documentation under fr/ so that it can be part of doctests? Just a brainstorm, perhaps it is not a good idea for various reasons.

[kcrisman]

Description changed:

--- 
+++ 
@@ -1,8 +1,8 @@
 in Sage 5.7 we get:
 
 ```
-sage: (x^2).simplify_radical()           
-x^2
+sage: sqrt(x^2).simplify_radical()           
+x
 ```
 This is wrong (consider x=-1 for example). Even:
 
@@ -11,6 +11,12 @@
 sage: sqrt(x^2).simplify_radical()
 x
 ```
+Previously it was 
+
+```
+sage: sqrt(x^2).simplify_radical()
+abs(x)
+```
 
 Note: this invalidates a whole part of our book (in french) about Sage at
 http://sagebook.gforge.inria.fr/

[kcrisman]

comment:2

This is the problem.

(%i1) radcan(sqrt(x^2));
(%o1)                               abs(x)
(%i2) domain:complex;
(%o2)                               complex
(%i3) radcan(sqrt(x^2));
(%o3)                                  x

Except this was not exposed before, apparently - it is the case in older Sage as well. This is due to #12780.

[zimmermann6]

comment:3

Karl-Dieter, I guess you mean #14308 instead of #14307?

Yes of course, in fact some chapters are already included, see tests/french_book.

Other chapters are waiting for work or reviewers: #10983, #11745. Feel free to help!

Paul

[kcrisman]

comment:4

This is the problem.

(%i1) radcan(sqrt(x^2));
(%o1)                               abs(x)
(%i2) domain:complex;
(%o2)                               complex
(%i3) radcan(sqrt(x^2));
(%o3)                                  x

By the way, I should point out that Maxima folks probably won't consider this a bug, for the same reasons as discussed in the past on other tickets, and expressed best by Richard Fateman here. But if we don't want this, we'll have to figure out how to deal with this.

Except this was not exposed before, apparently - it is the case in older Sage as well. This is due to #12780.

I've also posted a comment there, hopefully mjo or someone else will respond.

[zimmermann6]

comment:5

any news on this ticket?

Paul

[orlitzky]

comment:6

Jeroen asked a similar question a few months ago:

https://groups.google.com/forum/?fromgroups=#!topic/sage-support/jhCJujRtNA4/discussion

Maxima should notice that x is real (if you make the assumption), but it doesn't. The simplification of sqrt(x^2) to abs(x) relies on the "simplification domain" in Maxima being set to real -- in fact, if I remember correctly, that's the only thing the simplification domain does affect. To get the answer from sage <5.6, you'd need,

sage: maxima_lib.eval('domain: real;')
'real'
sage: sqrt(x^2).simplify()            
abs(x)

It sucks that you have to do that, and we should really add either a global method or a property of maxima_lib that lets you change it. That's one solution.

A better approach would be to notice when an expression contains only real variables, and to set the simplification domain appropriately. This could be done in either Maxima or Sage (pynac/ginac), but probably belongs in both. Symbols in sage have an associated domain, too:

sage: x = SR.symbol('x', domain='real')
sage: sqrt(x^2)
sqrt(x^2)

This never passes through Maxima, so arguably, Sage should simplify it if we can convince Maxima to do the same thing. But it's not at all easy to determine whether an expression is real; otherwise, I would have written it a long time ago! I mainly work over the reals myself and would love to have a solution that doesn't involve manually fooling with Maxima.

[zimmermann6]

comment:7

before #12780, the default domain was 'real', and sqrt(x^2).simplify_radical() was correctly simplified to abs(x).

After #12780, the default domain is that of Maxima (which is 'complex' in Sage 5.9), and sqrt(x^2).simplify_radical() is incorrectly simplified to x.

I believe the authors of #12780 should fix that issue.

Paul

[orlitzky]

comment:8

Replying to @zimmermann6:

before #12780, the default domain was 'real', and sqrt(x^2).simplify_radical() was correctly simplified to abs(x).

This isn't true. Before #12780, the domain everywhere in Sage except the simplify_radical function was 'complex'. The simplify_radical function would secretly change the domain to 'real', call radcan(), and then switch the domain back to 'complex'.

There is no simplification of sqrt(x^2) that is equal to abs(x), unless you know that x is real. Everywhere else in Sage, x is complex. Before sage-5.7, you got what you want, but you want a wrong answer.

I realize there's no other nice way to get the answer you want (that sucks, I want it too, it's not my fault, etc.), but that's not a good justification for adding back wrong behavior.

[nbruin]

comment:9

Replying to @orlitzky:

There is no simplification of sqrt(x^2) that is equal to abs(x), unless you know that x is real. Everywhere else in Sage, x is complex. Before sage-5.7, you got what you want, but you want a wrong answer.

I'm not sure you can dispose of the problem just by declaring it invalid. We do accept assume(x<0) and with that assumption in place the answer we get back really IS wrong (since the assumption implies that x is real). I know we're not going to fix/improve maxima's assumption system any time soon, but there are cases where this bug is going to be a "won't fix" rather than an "invalid".