Sage: Ticket #14305: Doctest: Immediate simplifications of symbolic powers
https://trac.sagemath.org/ticket/14305
<p>
in Sage 5.7 we get:
</p>
<pre class="wiki">sage: sqrt(x^2).simplify_radical()
x
</pre><p>
This is wrong (consider x=-1 for example). Even:
</p>
<pre class="wiki">sage: assume(x<0)
sage: sqrt(x^2).simplify_radical()
x
</pre><p>
Previously it was
</p>
<pre class="wiki">sage: sqrt(x^2).simplify_radical()
abs(x)
</pre><p>
Note: this invalidates a whole part of our book (in french) about Sage at
<a class="ext-link" href="http://sagebook.gforge.inria.fr/"><span class="icon"></span>http://sagebook.gforge.inria.fr/</a>
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/14305
Trac 1.1.6kcrismanTue, 19 Mar 2013 13:28:56 GMTdescription changed
https://trac.sagemath.org/ticket/14305#comment:1
https://trac.sagemath.org/ticket/14305#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/14305?action=diff&version=1">diff</a>)
</li>
</ul>
<p>
Regarding these three tickets (<a class="closed ticket" href="https://trac.sagemath.org/ticket/14305" title="defect: Doctest: Immediate simplifications of symbolic powers (closed: fixed)">#14305</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/14306" title="defect: regression in solve (closed: fixed)">#14306</a>, <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/14308" title="defect: unwanted maxima verbose output (needs_work)">#14308</a> (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.
</p>
TicketkcrismanTue, 19 Mar 2013 13:36:16 GMT
https://trac.sagemath.org/ticket/14305#comment:2
https://trac.sagemath.org/ticket/14305#comment:2
<p>
This is the problem.
</p>
<pre class="wiki">(%i1) radcan(sqrt(x^2));
(%o1) abs(x)
(%i2) domain:complex;
(%o2) complex
(%i3) radcan(sqrt(x^2));
(%o3) x
</pre><p>
Except this was not exposed before, apparently - it is the case in older Sage as well. This is due to <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>.
</p>
TicketzimmermaTue, 19 Mar 2013 13:41:00 GMT
https://trac.sagemath.org/ticket/14305#comment:3
https://trac.sagemath.org/ticket/14305#comment:3
<p>
Karl-Dieter, I guess you mean <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/14308" title="defect: unwanted maxima verbose output (needs_work)">#14308</a> instead of <a class="closed ticket" href="https://trac.sagemath.org/ticket/14307" title="defect: The new doctesting framework doesn't like being run with nohup (closed: fixed)">#14307</a>?
</p>
<p>
Yes of course, in fact some chapters are already included, see <code>tests/french_book</code>.
</p>
<p>
Other chapters are waiting for work or reviewers: <a class="closed ticket" href="https://trac.sagemath.org/ticket/10983" title="enhancement: new doctest for french book about Sage (closed: fixed)">#10983</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11745" title="enhancement: Some more doctests from the book "Calcul mathématique avec Sage" (closed: fixed)">#11745</a>. Feel free to help!
</p>
<p>
Paul
</p>
TicketkcrismanTue, 19 Mar 2013 13:46:14 GMTcc set
https://trac.sagemath.org/ticket/14305#comment:4
https://trac.sagemath.org/ticket/14305#comment:4
<ul>
<li><strong>cc</strong>
<em>mjo</em> <em>burcin</em> added
</li>
</ul>
<blockquote class="citation">
<p>
This is the problem.
</p>
<pre class="wiki">(%i1) radcan(sqrt(x^2));
(%o1) abs(x)
(%i2) domain:complex;
(%o2) complex
(%i3) radcan(sqrt(x^2));
(%o3) x
</pre></blockquote>
<p>
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 <a class="ext-link" href="http://ask.sagemath.org/question/767/simplification-errors-in-simple-expressions"><span class="icon"></span>Richard Fateman here</a>. But if we don't want this, we'll have to figure out how to deal with this.
</p>
<blockquote class="citation">
<p>
Except this was not exposed before, apparently - it is the case in older Sage as well. This is due to <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>.
</p>
</blockquote>
<p>
I've also posted a comment there, hopefully mjo or someone else will respond.
</p>
TicketzimmermaTue, 07 May 2013 09:02:14 GMT
https://trac.sagemath.org/ticket/14305#comment:5
https://trac.sagemath.org/ticket/14305#comment:5
<p>
any news on this ticket?
</p>
<p>
Paul
</p>
TicketmjoTue, 07 May 2013 15:01:36 GMT
https://trac.sagemath.org/ticket/14305#comment:6
https://trac.sagemath.org/ticket/14305#comment:6
<p>
Jeroen asked a similar question a few months ago:
</p>
<p>
<a class="ext-link" href="https://groups.google.com/forum/?fromgroups=#!topic/sage-support/jhCJujRtNA4/discussion"><span class="icon"></span>https://groups.google.com/forum/?fromgroups=#!topic/sage-support/jhCJujRtNA4/discussion</a>
</p>
<p>
Maxima should notice that <code>x</code> is real (if you make the assumption), but it doesn't. The simplification of <code>sqrt(x^2)</code> to <code>abs(x)</code> relies on the "simplification domain" in Maxima being set to <code>real</code> -- 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,
</p>
<pre class="wiki">sage: maxima_lib.eval('domain: real;')
'real'
sage: sqrt(x^2).simplify()
abs(x)
</pre><p>
It sucks that you have to do that, and we should really add either a global method or a property of <code>maxima_lib</code> that lets you change it. That's one solution.
</p>
<p>
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:
</p>
<pre class="wiki">sage: x = SR.symbol('x', domain='real')
sage: sqrt(x^2)
sqrt(x^2)
</pre><p>
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.
</p>
TicketzimmermaTue, 07 May 2013 18:43:44 GMT
https://trac.sagemath.org/ticket/14305#comment:7
https://trac.sagemath.org/ticket/14305#comment:7
<p>
before <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>, the default domain was 'real', and <code>sqrt(x^2).simplify_radical()</code> was correctly simplified to <code>abs(x)</code>.
</p>
<p>
After <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>, the default domain is that of Maxima (which is 'complex' in Sage 5.9), and <code>sqrt(x^2).simplify_radical()</code> is incorrectly simplified to <code>x</code>.
</p>
<p>
I believe the authors of <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a> should fix that issue.
</p>
<p>
Paul
</p>
TicketmjoTue, 07 May 2013 20:14:51 GMT
https://trac.sagemath.org/ticket/14305#comment:8
https://trac.sagemath.org/ticket/14305#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:7" title="Comment 7">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
before <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>, the default domain was 'real', and <code>sqrt(x^2).simplify_radical()</code> was correctly simplified to <code>abs(x)</code>.
</p>
</blockquote>
<p>
<br />
This isn't true. Before <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>, the domain everywhere in Sage <em>except the <code>simplify_radical</code> function</em> was 'complex'. The <code>simplify_radical</code> function would secretly change the domain to 'real', call <code>radcan()</code>, and then switch the domain back to 'complex'.
</p>
<p>
There is no simplification of <code>sqrt(x^2)</code> that is equal to <code>abs(x)</code>, unless you know that <code>x</code> is real. Everywhere else in Sage, <code>x</code> is complex. Before sage-5.7, you got what you want, but you want a wrong answer.
</p>
<p>
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.
</p>
TicketnbruinTue, 07 May 2013 20:34:54 GMT
https://trac.sagemath.org/ticket/14305#comment:9
https://trac.sagemath.org/ticket/14305#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:8" title="Comment 8">mjo</a>:
</p>
<blockquote class="citation">
<p>
There is no simplification of <code>sqrt(x^2)</code> that is equal to <code>abs(x)</code>, unless you know that <code>x</code> is real. Everywhere else in Sage, <code>x</code> is complex. Before sage-5.7, you got what you want, but you want a wrong answer.
</p>
</blockquote>
<p>
I'm not sure you can dispose of the problem just by declaring it invalid. We do accept <code>assume(x<0)</code> and with that assumption in place the answer we get back really IS wrong (since the assumption implies that <code>x</code> 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".
</p>
TicketmjoWed, 08 May 2013 00:16:32 GMT
https://trac.sagemath.org/ticket/14305#comment:10
https://trac.sagemath.org/ticket/14305#comment:10
<p>
We also accept <code>assume('x is a very pretty boy')</code>, so I'm not sure we should use that as our guide!
</p>
<p>
I'm not disagreeing that there should be an easy way to do this. Maxima should just simplify it when <code>x</code> is assumed real. That's probably the first bug I would target to get it fixed properly.
</p>
<p>
A second step would be to have ginac or pynac perform the same simplification on expressions of the simple form <code>sqrt(x^2)</code> where <code>x</code> is a single symbol and the domain of <code>x</code> is 'real'.
</p>
<p>
Finally (this is the most work), Maxima could be made to recognize when an expression <code>y</code> is real, and then, <code>simplify()</code> could turn <code>sqrt(y^2)</code> into <code>abs(y)</code>. Determining whether an expression is real or not seems rather complicated, though.
</p>
TicketmjoThu, 23 May 2013 00:54:03 GMT
https://trac.sagemath.org/ticket/14305#comment:11
https://trac.sagemath.org/ticket/14305#comment:11
<p>
Please take a look at <a class="closed ticket" href="https://trac.sagemath.org/ticket/14630" title="enhancement: Add `simplify_real` method to symbolic expressions (closed: fixed)">#14630</a> which provides an easy way to get this simplification.
</p>
TicketkcrismanThu, 23 May 2013 13:01:49 GMT
https://trac.sagemath.org/ticket/14305#comment:12
https://trac.sagemath.org/ticket/14305#comment:12
<p>
Thanks, that looks like a good step to take. Am I correct in saying it doesn't fix the <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:9" title="Comment 9">point Nils makes</a> about <code>assume(x<0)</code> (that is, when one doesn't use <a class="closed ticket" href="https://trac.sagemath.org/ticket/14630" title="enhancement: Add `simplify_real` method to symbolic expressions (closed: fixed)">#14630</a>, since the typical user would think it wasn't relevant...)?
</p>
TicketmjoFri, 24 May 2013 16:49:30 GMT
https://trac.sagemath.org/ticket/14305#comment:13
https://trac.sagemath.org/ticket/14305#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:12" title="Comment 12">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Thanks, that looks like a good step to take. Am I correct in saying it doesn't fix the <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:9" title="Comment 9">point Nils makes</a> about <code>assume(x<0)</code> (that is, when one doesn't use <a class="closed ticket" href="https://trac.sagemath.org/ticket/14630" title="enhancement: Add `simplify_real` method to symbolic expressions (closed: fixed)">#14630</a>, since the typical user would think it wasn't relevant...)?
</p>
</blockquote>
<p>
Correct, <a class="closed ticket" href="https://trac.sagemath.org/ticket/14630" title="enhancement: Add `simplify_real` method to symbolic expressions (closed: fixed)">#14630</a> just provides a way to get the simplification in the description, as an alternative to setting the Maxima domain manually.
</p>
TicketjdemeyerTue, 13 Aug 2013 15:34:36 GMTmilestone changed
https://trac.sagemath.org/ticket/14305#comment:14
https://trac.sagemath.org/ticket/14305#comment:14
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TicketzimmermaFri, 23 Aug 2013 14:31:06 GMT
https://trac.sagemath.org/ticket/14305#comment:15
https://trac.sagemath.org/ticket/14305#comment:15
<p>
while trying to see how we could tell Maxima that <code>x</code> is real after <code>assume(x>0)</code>, I noticed that the examples with <code>assume(x,'real')</code> in Sage are fake:
</p>
<p>
1) in <code>misc/functional.py</code> we have:
</p>
<pre class="wiki"> sage: a, b, c = var("a, b, c")
sage: assume((a, 'real'), (b, 'real'), (c, 'real'))
sage: z = a + b*I
sage: bool(norm(z).simplify() == a^2 + b^2)
True
</pre><p>
but the same works without <code>assume</code>:
</p>
<pre class="wiki">+--------------------------------------------------------------------+
| Sage Version 5.11, Release Date: 2013-08-13 |
| Type "notebook()" for the browser-based notebook interface. |
| Type "help()" for help. |
+--------------------------------------------------------------------+
sage: a, b, c = var("a, b, c")
sage: z = a + b*I
sage: norm(z).simplify()
a^2 + b^2
</pre><p>
2) in <code>symbolic/expression.pyx</code> we have
</p>
<pre class="wiki"> sage: a,b = var('a,b')
sage: assume((a, 'real'), (b, 'real'))
sage: f = a + b*I
sage: f.rectform()
a + I*b
</pre><p>
and again it works without <code>assume</code>:
</p>
<pre class="wiki">+--------------------------------------------------------------------+
| Sage Version 5.11, Release Date: 2013-08-13 |
| Type "notebook()" for the browser-based notebook interface. |
| Type "help()" for help. |
+--------------------------------------------------------------------+
sage: a,b = var('a,b')
sage: f = a + b*I
sage: f.rectform()
a + I*b
</pre><p>
Paul
</p>
TicketkcrismanFri, 23 Aug 2013 15:08:49 GMT
https://trac.sagemath.org/ticket/14305#comment:16
https://trac.sagemath.org/ticket/14305#comment:16
<p>
Interesting. Maybe that is a function of having upgraded Maxima or something? I presume that this wasn't the case at some time, but presumptions can be presumptuous.
</p>
TicketzimmermaFri, 23 Aug 2013 16:06:11 GMT
https://trac.sagemath.org/ticket/14305#comment:17
https://trac.sagemath.org/ticket/14305#comment:17
<p>
maybe <code>simplify</code> and <code>rectform</code> secretly change the domain of variables to the real domain (as <code>simplify_radical</code> previously did)?
</p>
<p>
Paul
</p>
TicketkcrismanFri, 23 Aug 2013 18:54:29 GMT
https://trac.sagemath.org/ticket/14305#comment:18
https://trac.sagemath.org/ticket/14305#comment:18
<p>
No, that is not it - <code>simplify</code> certainly doesn't, and <code>rectform</code> is just
</p>
<pre class="wiki">return self.maxima_methods().rectform()
</pre><p>
Sorry, that would have been easier to deal with. I particularly don't like the <code>rectform</code> example working without assuming real.
</p>
TicketmjoSat, 24 Aug 2013 16:54:25 GMT
https://trac.sagemath.org/ticket/14305#comment:19
https://trac.sagemath.org/ticket/14305#comment:19
<p>
I remember the first example, from <a class="closed ticket" href="https://trac.sagemath.org/ticket/12845" title="defect: Incorrect doctest in sage/misc/functional.py (closed: fixed)">#12845</a>. This is the full test:
</p>
<pre class="wiki">sage: a, b, c = var("a, b, c")
sage: assume((a, 'real'), (b, 'real'), (c, 'real'))
sage: z = a + b*I
sage: bool(norm(z).simplify() == a^2 + b^2)
True
sage: norm(a + b).simplify()
a^2 + 2*a*b + b^2
sage: v = vector([a, b, c])
sage: bool(norm(v).simplify() == sqrt(a^2 + b^2 + c^2))
True
sage: forget()
</pre><p>
The assumptions aren't needed for the first result, but they are for the last one (the norm of the vector).
</p>
<p>
The <code>rectform()</code> test is also mine, but the reasoning I've forgotten.
</p>
TicketzimmermaMon, 26 Aug 2013 08:15:58 GMT
https://trac.sagemath.org/ticket/14305#comment:20
https://trac.sagemath.org/ticket/14305#comment:20
<blockquote class="citation">
<p>
The assumptions aren't needed for the first result, but they are for the last one (the norm of the vector).
</p>
</blockquote>
<p>
maybe then the first test could be removed, if unrelated to <code>assume</code>?
Or at least the <code>assume</code> call moved after the first test?
</p>
<p>
Anyway the following is very annoying:
</p>
<pre class="wiki">sage: (x*conjugate(x)).simplify()
x^2
</pre><p>
Paul
</p>
TicketkcrismanMon, 26 Aug 2013 13:04:45 GMT
https://trac.sagemath.org/ticket/14305#comment:21
https://trac.sagemath.org/ticket/14305#comment:21
<blockquote class="citation">
<p>
Anyway the following is very annoying:
</p>
<pre class="wiki">sage: (x*conjugate(x)).simplify()
x^2
</pre></blockquote>
<p>
Wow, agreed. Unfortunately, Maxima needs to declare this.
</p>
<pre class="wiki">sage: assume(x,'complex')
sage: (x*conjugate(x)).simplify()
x*conjugate(x)
</pre><p>
I guess a possible workaround would be to have all SR variables declared <code>complex</code> in Maxima when first starting Maxima, and then thereafter... but it would be very hackish and slow.
</p>
TicketkcrismanMon, 26 Aug 2013 16:02:53 GMT
https://trac.sagemath.org/ticket/14305#comment:22
https://trac.sagemath.org/ticket/14305#comment:22
<p>
Turns out that it's possible to get all variables used so far in Maxima with <code>values</code>, and one could do a blanket <code>declare</code> on all of them. (Of course, one might not want to do this to all of them...) Fateman also has the following enigmatic response to me on the Maxima list.
</p>
<pre class="wiki">I think the understanding of complex variables is at best spotty, and if you want to do "a LOT" of
things with them you better check out exactly what Maxima does, and perhaps even make it work
with names that have no special properties.
</pre><p>
Anyway, I really don't want to go back to assuming things in Maxima on every variable defined in Sage (or even every SR variable) but I think we might have to go that way. Maybe there is a flag we could set as an underscore attribute in the SR vars indicating whether it has been declared complex in Maxima yet, which would be dealt with appropriately for ones which aren't complex, or have been assumed real, etc. - i.e., the <em>next</em> time one went into Maxima, they would be in a queue that was then declared complex. Not sure how hawkish that would be, but hopefully at least not slowing down Pynac variables appreciably.
</p>
TicketzimmermaTue, 27 Aug 2013 07:33:03 GMT
https://trac.sagemath.org/ticket/14305#comment:23
https://trac.sagemath.org/ticket/14305#comment:23
<blockquote class="citation">
<p>
a possible workaround would be to have all SR variables declared complex in Maxima
</p>
</blockquote>
<p>
indeed, maybe we could declare each new variable as complex whenever <code>var</code> is called (without <code>domain</code> argument or with <code>domain='complex'</code>).
This is by the way what the documentation of <code>var</code> says:
</p>
<pre class="wiki">sage: var?
...
By default, var returns a complex variable. To define real or
positive variables we can specify the domain as:
</pre><p>
Maybe we can add a call to <code>assume</code> in the function <code>symbol</code> of <code>symbolic/ring.pyx</code>?
</p>
<p>
Paul
</p>
TicketkcrismanTue, 27 Aug 2013 12:05:31 GMT
https://trac.sagemath.org/ticket/14305#comment:24
https://trac.sagemath.org/ticket/14305#comment:24
<p>
Unfortunately, that would
</p>
<ul><li>start up Maxima the first time, which takes quite a while
</li><li>use Maxima each and every time we create a symbolic variable, which would take some time
</li></ul><p>
I don't think people would be pleased with the slowdown this would cause. That's why I'm wondering whether there might be some other workaround along these lines but less draconian. Variables <em>are</em> complex by default, just not when we send them to Maxima.
</p>
TicketzimmermaTue, 27 Aug 2013 12:09:15 GMT
https://trac.sagemath.org/ticket/14305#comment:25
https://trac.sagemath.org/ticket/14305#comment:25
<p>
then we could record the list of created variables (with corresponding domains), and each time a <code>simplify</code> function from Maxima would be called, we could make the corresponding assumptions in Maxima, along the lines of what you suggest in comment <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:22" title="Comment 22">22</a>.
</p>
<p>
Paul
</p>
TicketburcinWed, 28 Aug 2013 17:47:02 GMT
https://trac.sagemath.org/ticket/14305#comment:26
https://trac.sagemath.org/ticket/14305#comment:26
<p>
The problem with the Maxima interface mixing up variable domains is <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/6862" title="defect: Mixing of different domains for symbolic variables (needs_work)">#6862</a>. This could be fixed with <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="defect: make sage variables unique in maxima (closed: fixed)">#8734</a> by changing the Maxima conversion (in the libmaxima interface) to work directly off the pynac expression tree (instead of going through strings / parsers) and set the corresponding flag in the temporary variables it creates. I'm not sure if anybody has time to implement this though.
</p>
TicketnbruinTue, 03 Sep 2013 18:54:33 GMT
https://trac.sagemath.org/ticket/14305#comment:27
https://trac.sagemath.org/ticket/14305#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:26" title="Comment 26">burcin</a>:
</p>
<blockquote class="citation">
<p>
The problem with the Maxima interface mixing up variable domains is <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/6862" title="defect: Mixing of different domains for symbolic variables (needs_work)">#6862</a>. This could be fixed with <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="defect: make sage variables unique in maxima (closed: fixed)">#8734</a> by changing the Maxima conversion (in the libmaxima interface) to work directly off the pynac expression tree (instead of going through strings / parsers)
</p>
</blockquote>
<p>
And that is largely available already via the functions <code>sage.interfaces.maxima_lib.sr_to_max</code> and <code>sage.interfaces.maxima_lib.max_to_sr</code>, which already get used for, for instance, limits and integrals. Currently it asks the strings-based translator (once) for how to convert, but the information is all there to convert variables more intelligently.
</p>
<p>
Of course, a formula translation routine can't go and purposely change the global state of maxima (you wouldn't know when to convert back!), but it could store required global settings somewhere else, so that they can be applied when the actual functionality is called upon and undone afterwards.
</p>
<p>
Implementing this will indeed be a tedious and thankless job. It would feel a lot more worthwhile if first almost all of calculus were moved to using <code>sr_to_max</code>. Then is gets easier to start letting maxima_lib have different conversion semantics than maxima.
</p>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/14305#comment:28
https://trac.sagemath.org/ticket/14305#comment:28
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:19:32 GMTmilestone changed
https://trac.sagemath.org/ticket/14305#comment:29
https://trac.sagemath.org/ticket/14305#comment:29
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/14305#comment:30
https://trac.sagemath.org/ticket/14305#comment:30
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketkcrismanSat, 06 Dec 2014 20:22:44 GMTcc, summary changed
https://trac.sagemath.org/ticket/14305#comment:31
https://trac.sagemath.org/ticket/14305#comment:31
<ul>
<li><strong>cc</strong>
<em>rws</em> added
</li>
<li><strong>summary</strong>
changed from <em>bug in simplify_radical</em> to <em>Clarify assumptions and domains in Maxima</em>
</li>
</ul>
<p>
Changing the description, as this isn't really about <code>simplify_radical</code>/its successor any more. In fact, I'm not really sure what this one is about, but I feel like <a class="closed ticket" href="https://trac.sagemath.org/ticket/14630" title="enhancement: Add `simplify_real` method to symbolic expressions (closed: fixed)">#14630</a> and <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/6862" title="defect: Mixing of different domains for symbolic variables (needs_work)">#6862</a> don't cover everything mentioned here.
</p>
TicketrwsFri, 23 Jun 2017 14:55:13 GMTdependencies set
https://trac.sagemath.org/ticket/14305#comment:32
https://trac.sagemath.org/ticket/14305#comment:32
<ul>
<li><strong>dependencies</strong>
set to <em>pynac-0.7.9</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:10" title="Comment 10">mjo</a>:
</p>
<blockquote class="citation">
<p>
A second step would be to have ginac or pynac perform the same simplification on expressions of the simple form <code>sqrt(x^2)</code> where <code>x</code> is a single symbol and the domain of <code>x</code> is 'real'.
</p>
</blockquote>
<p>
I believe this is fixed in Pynac master:
<a class="ext-link" href="https://github.com/pynac/pynac/commit/0a3979a4ed8bdb3ed1be4c6ee5d328a9b2c690b8"><span class="icon"></span>https://github.com/pynac/pynac/commit/0a3979a4ed8bdb3ed1be4c6ee5d328a9b2c690b8</a>
</p>
<pre class="wiki">sage: sqrt(x^2)
sqrt(x^2)
sage: x = SR.symbol('x', domain='real')
sage: sqrt(x^2)
abs(x)
sage: forget()
sage: assume(x<0)
sage: sqrt(x^2)
-x
sage: sqrt(x^4)
x^2
sage: forget()
sage: x = SR.symbol('x', domain='real')
sage: sqrt(x^4)
x^2
sage: sqrt(sin(x)^2)
abs(sin(x))
sage: sqrt((x+1)^2)
abs(x + 1)
sage: (x^3)^(1/3)
(x^3)^(1/3)
sage: (x^4)^(1/4)
abs(x)
sage: (x^8)^(1/4)
x^2
sage: (x^-4)^(1/4)
1/abs(x)
sage: (x^-8)^(1/4)
x^(-2)
sage: forget()
sage: assume(x<0)
sage: sqrt((x-1)^2)
-x + 1
</pre><p>
This is immediate expansion. You can see it's not restricted to the inner exponent <code>2</code>, and it also works on arbitrary expressions not just symbols.
</p>
<p>
The ticket should add the above (or any additions) as doctests.
</p>
TicketrwsMon, 26 Jun 2017 07:51:07 GMTdependencies changed
https://trac.sagemath.org/ticket/14305#comment:33
https://trac.sagemath.org/ticket/14305#comment:33
<ul>
<li><strong>dependencies</strong>
changed from <em>pynac-0.7.9</em> to <em>#23325</em>
</li>
</ul>
TicketrwsWed, 06 Sep 2017 05:34:41 GMTbranch set
https://trac.sagemath.org/ticket/14305#comment:34
https://trac.sagemath.org/ticket/14305#comment:34
<ul>
<li><strong>branch</strong>
set to <em>u/rws/clarify_assumptions_and_domains_in_maxima</em>
</li>
</ul>
TicketrwsWed, 06 Sep 2017 05:35:51 GMTstatus, summary, milestone changed; commit, author set
https://trac.sagemath.org/ticket/14305#comment:35
https://trac.sagemath.org/ticket/14305#comment:35
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
set to <em>6125bd6f28f36c29752c3bf7cfba0c206652ec65</em>
</li>
<li><strong>author</strong>
set to <em>Ralf Stephan</em>
</li>
<li><strong>summary</strong>
changed from <em>Clarify assumptions and domains in Maxima</em> to <em>Doctest: Immediate simplifications of symbolic powers</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-8.1</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=6125bd6f28f36c29752c3bf7cfba0c206652ec65"><span class="icon"></span>6125bd6</a></td><td><code>14305: Doctest: Immediate simplifications of symbolic powers</code>
</td></tr></table>
TicketzimmermaWed, 06 Sep 2017 06:43:34 GMT
https://trac.sagemath.org/ticket/14305#comment:36
https://trac.sagemath.org/ticket/14305#comment:36
<p>
a small typo:
<code>Immediate simplification are applied</code>
should be:
<code>Immediate simplifications are applied</code>.
</p>
TicketgitWed, 06 Sep 2017 07:07:14 GMTcommit changed
https://trac.sagemath.org/ticket/14305#comment:37
https://trac.sagemath.org/ticket/14305#comment:37
<ul>
<li><strong>commit</strong>
changed from <em>6125bd6f28f36c29752c3bf7cfba0c206652ec65</em> to <em>e5d5ba0b7b43dd21852984d6f43c28ef334d5890</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=e5d5ba0b7b43dd21852984d6f43c28ef334d5890"><span class="icon"></span>e5d5ba0</a></td><td><code>14305: fix typo</code>
</td></tr></table>
TicketjdemeyerWed, 25 Oct 2017 13:25:09 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/14305#comment:38
https://trac.sagemath.org/ticket/14305#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Jeroen Demeyer</em>
</li>
</ul>
TicketrwsWed, 25 Oct 2017 13:33:43 GMT
https://trac.sagemath.org/ticket/14305#comment:39
https://trac.sagemath.org/ticket/14305#comment:39
<p>
Thanks.
</p>
TicketjdemeyerWed, 25 Oct 2017 13:37:59 GMT
https://trac.sagemath.org/ticket/14305#comment:40
https://trac.sagemath.org/ticket/14305#comment:40
<p>
I wonder why <code>(x^3)^(1/3)</code> is not simplified for real <code>x</code> though...
</p>
TicketzimmermaWed, 25 Oct 2017 13:42:03 GMT
https://trac.sagemath.org/ticket/14305#comment:41
https://trac.sagemath.org/ticket/14305#comment:41
<p>
try <code>x=-1</code>...
</p>
TicketrwsWed, 25 Oct 2017 13:45:35 GMT
https://trac.sagemath.org/ticket/14305#comment:42
https://trac.sagemath.org/ticket/14305#comment:42
<pre class="wiki">sage: var(x, domain='real')
x
sage: (x^3)^(1/3)
(x^3)^(1/3)
sage: assume(x > 0)
sage: (x^3)^(1/3)
x
</pre>
TicketjdemeyerWed, 25 Oct 2017 13:48:12 GMT
https://trac.sagemath.org/ticket/14305#comment:43
https://trac.sagemath.org/ticket/14305#comment:43
<p>
I don't get this. Why should it matter whether <code>x < 0</code> or <code>x > 0</code>?
</p>
<p>
Why is it valid to say that <code>1^(1/3) = 1</code> but not <code>(-1)^(1/3) = -1</code> for real numbers?
</p>
TicketrwsWed, 25 Oct 2017 14:09:33 GMT
https://trac.sagemath.org/ticket/14305#comment:44
https://trac.sagemath.org/ticket/14305#comment:44
<p>
I opened <a class="ext-link" href="https://github.com/pynac/pynac/issues/283"><span class="icon"></span>https://github.com/pynac/pynac/issues/283</a>
</p>
TicketzimmermaWed, 25 Oct 2017 14:25:39 GMT
https://trac.sagemath.org/ticket/14305#comment:45
https://trac.sagemath.org/ticket/14305#comment:45
<p>
z<sup>1/n</sup> for z a complex number is defined as the principal branch, which is that having the least argument, see for example <a class="ext-link" href="https://en.wikipedia.org/wiki/Nth_root"><span class="icon"></span>https://en.wikipedia.org/wiki/Nth_root</a>.
</p>
<p>
Thus the square root of -1 is I, having argument pi/2, whereas -I has argument 3*pi/2.
</p>
<p>
The cube root of -1 is 1/2 + I*sqrt(3)/2, having argument pi/3.
</p>
TicketrwsWed, 25 Oct 2017 14:33:41 GMT
https://trac.sagemath.org/ticket/14305#comment:46
https://trac.sagemath.org/ticket/14305#comment:46
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:45" title="Comment 45">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
The cube root of -1 is 1/2 + I*sqrt(3)/2, having argument pi/3.
</p>
</blockquote>
<p>
One or three cube roots of -1 exist?
</p>
TicketzimmermaWed, 25 Oct 2017 14:49:07 GMT
https://trac.sagemath.org/ticket/14305#comment:47
https://trac.sagemath.org/ticket/14305#comment:47
<p>
there are three complex numbers <code>t</code> such that <code>t^3=z</code>, but when you write <code>z^(1/3)</code>, the computer algebra system must choose one of them, for example to evaluate numerically, and the usual choice is the principal branch.
</p>
<p>
I recommend reading the paper "Branch Cuts in Computer Algebra" by Adam Dingle and Richard Fateman.
</p>
TicketrwsWed, 25 Oct 2017 15:27:32 GMT
https://trac.sagemath.org/ticket/14305#comment:48
https://trac.sagemath.org/ticket/14305#comment:48
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:47" title="Comment 47">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
there are three complex numbers <code>t</code> such that <code>t^3=z</code>, but when you write <code>z^(1/3)</code>, the computer algebra system must choose one of them, for example to evaluate numerically, and the usual choice is the principal branch.
</p>
<p>
I recommend reading the paper "Branch Cuts in Computer Algebra" by Adam Dingle and Richard Fateman.
</p>
</blockquote>
<p>
I'm not evaluating numerically, <code>t^3=z</code> does not per se represent a function, just an expression. If your argument were true, I could not even solve for -1.
</p>
TicketrwsWed, 25 Oct 2017 15:31:27 GMT
https://trac.sagemath.org/ticket/14305#comment:49
https://trac.sagemath.org/ticket/14305#comment:49
<p>
I mean why do I even argument, Jeroen is a better math, so I trust him when he objects.
</p>
TicketrwsWed, 25 Oct 2017 15:38:44 GMT
https://trac.sagemath.org/ticket/14305#comment:50
https://trac.sagemath.org/ticket/14305#comment:50
<p>
Paul, maybe the problem is that you transfer the fact that RR is in CC to that "expressions with real variables" behave like "expressions with complex variables"?
</p>
TicketjdemeyerWed, 25 Oct 2017 15:41:23 GMT
https://trac.sagemath.org/ticket/14305#comment:51
https://trac.sagemath.org/ticket/14305#comment:51
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:49" title="Comment 49">rws</a>:
</p>
<blockquote class="citation">
<p>
Jeroen is a better math, so I trust him when he objects.
</p>
</blockquote>
<p>
Not sure why you say that. I understand Paul's reasoning. It's hard to tell who is right. If only variables have a domain (as opposed to constants), then <code>(-1)^(1/3)</code> must indeed evaluate to a complex number because we can't guess whether the <code>-1</code> represents the real or complex <code>-1</code>.
</p>
TicketrwsWed, 25 Oct 2017 15:52:08 GMT
https://trac.sagemath.org/ticket/14305#comment:52
https://trac.sagemath.org/ticket/14305#comment:52
<p>
A complex function is not necessarily a complex-variable function, that's maybe the mistake I made.
</p>
TicketzimmermaWed, 25 Oct 2017 15:56:14 GMT
https://trac.sagemath.org/ticket/14305#comment:53
https://trac.sagemath.org/ticket/14305#comment:53
<p>
indeed we cannot know in advance whether <code>-1</code> represents a real or complex number.
However, another point is that the "simplication rule" should be consistent between the real and complex numbers: when a complex number <code>z</code> tends to the real number <code>-1</code>, you want that <code>z^(1/3)</code> tends to <code>(-1)^(1/3)</code>, except maybe on a line (called the branch cut) going out from 0. The principal branch gives this consistency.
</p>
TicketmjoWed, 25 Oct 2017 16:02:59 GMT
https://trac.sagemath.org/ticket/14305#comment:54
https://trac.sagemath.org/ticket/14305#comment:54
<p>
This is messy largely because we have never decided on what <code>sqrt</code> or e.g. <code>x^(1/3)</code> is supposed to do, particularly when applied to a symbolic expression.
</p>
<ul><li>Is it a function from the real numbers to the real numbers (choose the positive root)?
</li><li>Is it a function from the complex numbers to the complex numbers (choose the principal branch)?
</li><li>Is the codomain of <code>sqrt</code> the same as a "domain" of its argument? For example, if <code>x</code> is a variable with <code>domain=real</code>, should <code>sqrt(x)</code> be an expression whose domain is <code>"real"</code>?
</li><li>Do we want <code>sqrt</code> and friends to be functions at all? When solving equations, it'd be nice if we had access to both square roots.
</li></ul><p>
etc.
</p>
<p>
If you ask five different people, you'll get five different answers. I'm wary of any "simplification" that might return an incorrect result to any of those people: simplification should be unambiguous and obviously correct. Any other more-powerful but less-straightforward operation should be called something else, like we've done with <code>x.canonicalize_radical()</code>.
</p>
TicketrwsWed, 25 Oct 2017 16:17:30 GMT
https://trac.sagemath.org/ticket/14305#comment:55
https://trac.sagemath.org/ticket/14305#comment:55
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/14305#comment:49" title="Comment 49">rws</a>:
</p>
<blockquote class="citation">
<p>
I mean why do I even argument, Jeroen is a better math, so I trust him when he objects.
</p>
</blockquote>
<p>
I just reread that and yes I forgot to add "than me", opening unintended interpretations.
</p>
TicketkcrismanWed, 25 Oct 2017 17:26:46 GMT
https://trac.sagemath.org/ticket/14305#comment:56
https://trac.sagemath.org/ticket/14305#comment:56
<blockquote class="citation">
<p>
If you ask five different people, you'll get five different answers. I'm wary of any "simplification" that might return an incorrect result to any of those people: simplification should be unambiguous and obviously correct. Any other more-powerful but less-straightforward operation should be called something else, like we've done with x.canonicalize_radical().
</p>
</blockquote>
<p>
Correct, this whole thread is exactly the same thing. Basically, is <code>sqrt(x)</code> a symbol or a function? If you want long (and undoubtedly correct in at least one interpretation) answers to this, ask Fateman :-) with whom we had long discussions about it.
</p>
TicketvbraunSun, 29 Oct 2017 10:32:25 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/14305#comment:57
https://trac.sagemath.org/ticket/14305#comment:57
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/rws/clarify_assumptions_and_domains_in_maxima</em> to <em>e5d5ba0b7b43dd21852984d6f43c28ef334d5890</em>
</li>
</ul>
Ticket