Sage: Ticket #15605: (-1)^(2/3) evaluates to 1
https://trac.sagemath.org/ticket/15605
<p>
Likely a duplicate, but I couldn't find it elsewhere...
</p>
<pre class="wiki">sage: (-1)^(2/3)
1
</pre><p>
Of course, this is inconsistent with virtually all interpretations and conversions of symbolic expressions...
</p>
<pre class="wiki">sage: CC(-1)^(2/3)
-0.500000000000000 + 0.866025403784439*I
sage: QQbar(-1)^(2/3)
-0.500000000000000? + 0.866025403784439?*I
sage: RR(-1)^(2/3)
-0.500000000000000 + 0.866025403784439*I
</pre><p>
Also:
</p>
<pre class="wiki">sage: (-1)^(-1/3)
-1
sage: 1 / ((-1)^(1/3))
-1
</pre><pre class="wiki">sage: (-1)^(1/3)*(-1)^(1/5)
1
</pre><p>
but
</p>
<pre class="wiki">sage: (-1)^(1/15)
(-1)^(1/15)
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/15605
Trac 1.1.6mmezzarobbaSun, 29 Dec 2013 09:25:49 GMTdescription changed
https://trac.sagemath.org/ticket/15605#comment:1
https://trac.sagemath.org/ticket/15605#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15605?action=diff&version=1">diff</a>)
</li>
</ul>
TicketmmezzarobbaSun, 29 Dec 2013 09:34:23 GMTdescription changed
https://trac.sagemath.org/ticket/15605#comment:2
https://trac.sagemath.org/ticket/15605#comment:2
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15605?action=diff&version=2">diff</a>)
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/15605#comment:3
https://trac.sagemath.org/ticket/15605#comment:3
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketchapotonFri, 07 Mar 2014 21:22:54 GMTdescription changed
https://trac.sagemath.org/ticket/15605#comment:4
https://trac.sagemath.org/ticket/15605#comment:4
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15605?action=diff&version=4">diff</a>)
</li>
</ul>
<p>
Seems to be a problem about "even" powers:
</p>
<pre class="wiki">sage: [(-1)^(i/77) for i in range(9)]
[1, (-1)^(1/77), 1, (-1)^(3/77), 1, (-1)^(5/77), 1, (-1)^(1/11), 1]
</pre>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/15605#comment:5
https://trac.sagemath.org/ticket/15605#comment:5
<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/15605#comment:6
https://trac.sagemath.org/ticket/15605#comment:6
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TickettmonteilTue, 07 Apr 2015 23:13:03 GMT
https://trac.sagemath.org/ticket/15605#comment:7
https://trac.sagemath.org/ticket/15605#comment:7
<p>
Replying to <a class="closed ticket" href="https://trac.sagemath.org/ticket/15605" title="defect: (-1)^(2/3) evaluates to 1 (closed: fixed)">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Likely a duplicate, but I couldn't find it elsewhere...
</p>
</blockquote>
<p>
It is indeed a known issue since at least <a class="ext-link" href="http://ask.sagemath.org/question/10063/get-variants-of-complex-cube-root/?answer=14842#post-id-14842"><span class="icon"></span>this ask answer</a>, and i use this example in my presentations about Sage and the need to define objects within a reliable parent.
</p>
<p>
I did not report that on trac because this is somehow a feature of the symbolic ring : no semantics. I remember a discussion with you at sd49 (Orsay) about that precise example and the benefits (or not!) of having such kind of symbolic expressions that are able to make all kind of simplifications/derivatives/evaluations without context.
</p>
<p>
If one want to have something that both:
</p>
<ul><li>applies rules such as <code>a^(bc) = (a^b)^c</code> systematically,
</li><li>takes principal branches of multi-valued complex function when evaluating,
</li></ul><p>
then we should accept that kind of behaviour.
</p>
<p>
It would however be awesome to have a well-designed object to work with holomorphic functions, along the same lines that what is done with polynomials, i guess it is a very hard task, and i do not know whether there exists libraries for that.
</p>
TicketrwsWed, 08 Apr 2015 06:29:37 GMT
https://trac.sagemath.org/ticket/15605#comment:8
https://trac.sagemath.org/ticket/15605#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:7" title="Comment 7">tmonteil</a>:
</p>
<blockquote class="citation">
<p>
If one want to have something that both:
</p>
<ul><li>applies rules such as <code>a^(bc) = (a^b)^c</code> systematically,
</li><li>takes principal branches of multi-valued complex function when evaluating,
</li></ul><p>
then we should accept that kind of behaviour.
</p>
</blockquote>
<p>
I think that with <code>bc</code> numeric (and it only makes sense to me if rational) and <code>a</code> negative the rule <code>a^(bc) = (a^b)^c</code> should not be applied simply because then <code>a^b</code> loses information. With symbolic exponent the user will probaby expect simplification.
</p>
TicketmmezzarobbaWed, 08 Apr 2015 08:32:04 GMT
https://trac.sagemath.org/ticket/15605#comment:9
https://trac.sagemath.org/ticket/15605#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:7" title="Comment 7">tmonteil</a>:
</p>
<blockquote class="citation">
<p>
this is somehow a feature of the symbolic ring : no semantics.
</p>
</blockquote>
<p>
I agree in part only. Sure, general symbolic expressions have very weak semantics—essentially, I view them as straight-line programs that are just required to evaluate to what you'd expect when you assign values to free variables. Many <em>operations</em> on symbolic expressions, however, only make sense with stronger assumptions on the expressions. Typically, simplifications are supposed to transform these ”programs“ into ”equivalent“ ones, but of course whether two ”programs“ are equivalent depends on what the variables can represent.
</p>
<p>
The sensible thing to do IMO is to view all variables as complex by default, and require simplifications to be valid for arbitrary complex values of all variables (or more accurately, for a generic choice of complex values: for example, we probably do want <code>x/x</code> to simplify to <code>1</code>). At least what's what Maple does, and Maple arguably has the best implementation of ”general symbolic expressions” over there.
</p>
<p>
We'll still get nonsense in many cases when trying to simplify expressions containing constants from finite fields or other parents that do not fit well into this model, but I don't know how to avoid that. (Something that may be worth trying would be to define new symbolic ”rings“ parametrized by a parent. For instance, in <code>SR(QQ)</code>, all variables would be assumed to represent elements of <code>QQ</code>, constants would automatically be coerced into <code>QQ</code>, and arithmetic operations between constants would take place there. But that's not how the existing <code>SR</code> works.)
</p>
<blockquote class="citation">
<p>
If one want to have something that both:
</p>
<ul><li>applies rules such as <code>a^(bc) = (a^b)^c</code> systematically,
</li></ul></blockquote>
<p>
I don't think we want that. IMO this rule should be applied only if either assumptions on <code>a</code>, <code>b</code>, <code>c</code> make it safe (e.g., <code>c</code> is known to be an integer) or the user explicitely asked for it. Of course, safe simplification routines are more cumbersome to use. To mitigate the issue, Maple's <code>simplify</code> accepts an option (<code>symbolic</code>) that tells it to disregard all analytical issues related to multivalued functions and just take any branch it likes. Something like that would be convenient in Sage as well.
</p>
TicketvdelecroixWed, 08 Apr 2015 08:55:52 GMTcc set
https://trac.sagemath.org/ticket/15605#comment:10
https://trac.sagemath.org/ticket/15605#comment:10
<ul>
<li><strong>cc</strong>
<em>vdelecroix</em> added
</li>
</ul>
TicketvdelecroixWed, 08 Apr 2015 08:59:42 GMTdescription changed
https://trac.sagemath.org/ticket/15605#comment:11
https://trac.sagemath.org/ticket/15605#comment:11
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15605?action=diff&version=11">diff</a>)
</li>
</ul>
TicketvdelecroixWed, 08 Apr 2015 09:10:58 GMT
https://trac.sagemath.org/ticket/15605#comment:12
https://trac.sagemath.org/ticket/15605#comment:12
<p>
Just to give some concrete motivations, in <a class="needs_info ticket" href="https://trac.sagemath.org/ticket/16222" title="enhancement: Faster exactification using numeric minpoly (needs_info)">#16222</a> (and <a class="new ticket" href="https://trac.sagemath.org/ticket/17516" title="enhancement: Radical expressions for roots of polynomials using Galois theory (new)">#17516</a>) we need a rather small subsets of symbolic expressions that modelize (some) algebraic numbers. Namely:
</p>
<ul><li>no variable
</li><li>rational coefficients
</li><li>I
</li><li>exp(2*I*pi*a), cos(2*pi*a), sin(2*pi*a) with a rational
</li><li>rational powers
</li><li>taking real and imaginary parts
</li></ul><p>
An example of such expression is
</p>
<pre class="wiki">((cos(pi/7) + (-1)^(1/3))^(2/3)).real()
</pre><p>
Do you think this must be out of the symbolic ring?
</p>
<p>
Vincent
</p>
TicketmmezzarobbaWed, 08 Apr 2015 16:38:49 GMT
https://trac.sagemath.org/ticket/15605#comment:13
https://trac.sagemath.org/ticket/15605#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:12" title="Comment 12">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Do you think this must be out of the symbolic ring?
</p>
</blockquote>
<p>
I for one don't really see a problem with using the symbolic ring, but it depends if you have more use cases in mind.
</p>
TicketvdelecroixFri, 10 Apr 2015 11:12:01 GMT
https://trac.sagemath.org/ticket/15605#comment:14
https://trac.sagemath.org/ticket/15605#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:13" title="Comment 13">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:12" title="Comment 12">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Do you think this must be out of the symbolic ring?
</p>
</blockquote>
<p>
I for one don't really see a problem with using the symbolic ring, but it depends if you have more use cases in mind.
</p>
</blockquote>
<p>
Here is one problem with using the symbolic ring for constants:
</p>
<pre class="wiki">sage: 0.1 * cos(pi/13)
0.100000000000000*cos(1/13*pi)
</pre><p>
The answer should be a floating point real number!
</p>
<p>
Vincent
</p>
TicketmmezzarobbaFri, 10 Apr 2015 14:52:28 GMT
https://trac.sagemath.org/ticket/15605#comment:15
https://trac.sagemath.org/ticket/15605#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:14" title="Comment 14">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Here is one problem with using the symbolic ring for constants:
</p>
<pre class="wiki">sage: 0.1 * cos(pi/13)
0.100000000000000*cos(1/13*pi)
</pre><p>
The answer should be a floating point real number!
</p>
</blockquote>
<p>
Yes, perhaps, I'm not sure. Perhaps it should be a symbolic expression wrapping a FP number. Or perhaps it should just stay unevaluated. For instance, if <code>0.1 * cos(pi/13)</code> evaluates to a FP number, what should <code>0.1 * x * cos(pi/13)</code> do?
</p>
TicketvdelecroixFri, 10 Apr 2015 15:04:01 GMT
https://trac.sagemath.org/ticket/15605#comment:16
https://trac.sagemath.org/ticket/15605#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:15" title="Comment 15">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:14" title="Comment 14">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Here is one problem with using the symbolic ring for constants:
</p>
<pre class="wiki">sage: 0.1 * cos(pi/13)
0.100000000000000*cos(1/13*pi)
</pre><p>
The answer should be a floating point real number!
</p>
</blockquote>
<p>
Yes, perhaps, I'm not sure. Perhaps it should be a symbolic expression wrapping a FP number. Or perhaps it should just stay unevaluated. For instance, if <code>0.1 * cos(pi/13)</code> evaluates to a FP number, what should <code>0.1 * x * cos(pi/13)</code> do?
</p>
</blockquote>
<p>
<code>0.1 * x * cos(pi/13)</code> should be an element of the symbolic ring (which might not necessarily be equal to <code>0.1 * cos(pi/13) * x</code>). As soon as a variable appear, just go to the symbolic ring. I do not want to remove it, just to get off some part of it that would make something coherent.
</p>
<p>
This is why I am arguing for having a new intermediate world:
</p>
<ul><li>symbolic ring (the same as today),
</li><li>some rings of symbolic constants, explicitely embedded in RR or CC, in which equality is known to be decidable (for example the one I mentioned above).
</li></ul><p>
Having some <code>False</code> positive is also very annoying with respect to my perspective.
</p>
<p>
Vincent
</p>
TicketrwsSun, 14 Jun 2015 07:08:14 GMT
https://trac.sagemath.org/ticket/15605#comment:17
https://trac.sagemath.org/ticket/15605#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:15" title="Comment 15">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15605#comment:14" title="Comment 14">vdelecroix</a>:
</p>
<blockquote class="citation">
<p>
Here is one problem with using the symbolic ring for constants:
</p>
<pre class="wiki">sage: 0.1 * cos(pi/13)
0.100000000000000*cos(1/13*pi)
</pre><p>
The answer should be a floating point real number!
</p>
</blockquote>
<p>
Yes, perhaps, I'm not sure. Perhaps it should be a symbolic expression wrapping a FP number. Or perhaps it should just stay unevaluated. For instance, if <code>0.1 * cos(pi/13)</code> evaluates to a FP number, what should <code>0.1 * x * cos(pi/13)</code> do?
</p>
</blockquote>
<p>
But that would be then a different case? Anyway, the non-symbolic issue is now <a class="new ticket" href="https://trac.sagemath.org/ticket/18697" title="defect: any FP number in an Expression without symbol should trigger evaluation (new)">#18697</a>.
</p>
TicketrwsMon, 05 Dec 2016 16:35:48 GMT
https://trac.sagemath.org/ticket/15605#comment:18
https://trac.sagemath.org/ticket/15605#comment:18
<p>
Back to the original issue. The actual problem is in the Pynac logic for powers where usually the Python / Cython code for <code>Rational.rational_power_parts</code> is called and used. Apparently to speed things up this is only called if a numeric computation does not return a rational (which does not work as expected).
</p>
<p>
However, we cannot just say always use <code>rational_power_parts</code> because that is wrong too,
</p>
<pre class="wiki">sage: from sage.rings.rational import rational_power_parts
sage: rational_power_parts(-1,1/3)
(1, -1)
sage: rational_power_parts(-1,2/3)
(1, 1)
sage: [rational_power_parts(-1, i/77) for i in range(9)]
[(1, 1), (1, -1), (1, 1), (1, -1), (1, 1), (1, -1), (1, 1), (1, -1), (1, 1)]
</pre><p>
i.e. both wrong results in the following are from independent bugs:
</p>
<pre class="wiki">sage: SR(-1)^(2/3)
1
sage: QQ(-1)^(2/3)
1
</pre>
TicketrwsMon, 05 Dec 2016 16:40:03 GMT
https://trac.sagemath.org/ticket/15605#comment:19
https://trac.sagemath.org/ticket/15605#comment:19
<p>
The symbolic issue is <a class="ext-link" href="https://github.com/pynac/pynac/issues/221"><span class="icon"></span>https://github.com/pynac/pynac/issues/221</a>. We can then fix the Cython code in the rational ring, as well.
</p>
TicketrwsWed, 07 Dec 2016 07:45:02 GMTbranch set
https://trac.sagemath.org/ticket/15605#comment:20
https://trac.sagemath.org/ticket/15605#comment:20
<ul>
<li><strong>branch</strong>
set to <em>u/rws/__1___2_3__evaluates_to_1</em>
</li>
</ul>
TicketgitWed, 07 Dec 2016 07:46:33 GMTcommit set
https://trac.sagemath.org/ticket/15605#comment:21
https://trac.sagemath.org/ticket/15605#comment:21
<ul>
<li><strong>commit</strong>
set to <em>046c9f9c4c8e465af7ed5799267b4162639f7eac</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=046c9f9c4c8e465af7ed5799267b4162639f7eac"><span class="icon"></span>046c9f9</a></td><td><code>15605: -1 special case was badly handled</code>
</td></tr></table>
TicketrwsWed, 07 Dec 2016 07:48:31 GMTstatus, milestone changed; author set
https://trac.sagemath.org/ticket/15605#comment:22
https://trac.sagemath.org/ticket/15605#comment:22
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>author</strong>
set to <em>Ralf Stephan</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-7.6</em>
</li>
</ul>
<p>
Actually fixing this in <code>rational.pyx</code> fixes both instances.
</p>
TicketvdelecroixMon, 12 Dec 2016 12:58:13 GMT
https://trac.sagemath.org/ticket/15605#comment:23
https://trac.sagemath.org/ticket/15605#comment:23
<p>
Nice!
</p>
<p>
Some more tests
</p>
<pre class="wiki">sage: bool((-1)^(2/3) == -1/2 + sqrt(3)/2*I)
True
sage: all((-1)^(p/q) == cos(p*pi/q) + I * sin(p*pi/q) for p in srange(1,6) for q in srange(1,6))
True
</pre>
TicketgitMon, 12 Dec 2016 14:05:34 GMTcommit changed
https://trac.sagemath.org/ticket/15605#comment:24
https://trac.sagemath.org/ticket/15605#comment:24
<ul>
<li><strong>commit</strong>
changed from <em>046c9f9c4c8e465af7ed5799267b4162639f7eac</em> to <em>69f75eccbfeb3dbd370f382f6a4129a12a86d7da</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=c1f15835c67e8deb34fc979d942e59e9c9e5fe66"><span class="icon"></span>c1f1583</a></td><td><code>Merge branch 'develop' into t/15605/__1___2_3__evaluates_to_1</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=69f75eccbfeb3dbd370f382f6a4129a12a86d7da"><span class="icon"></span>69f75ec</a></td><td><code>more tests</code>
</td></tr></table>
TicketvdelecroixMon, 12 Dec 2016 14:06:56 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/15605#comment:25
https://trac.sagemath.org/ticket/15605#comment:25
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Vincent Delecroix</em>
</li>
</ul>
<p>
good enough. Thanks for the fix!
</p>
TicketrwsMon, 12 Dec 2016 14:21:16 GMT
https://trac.sagemath.org/ticket/15605#comment:26
https://trac.sagemath.org/ticket/15605#comment:26
<p>
Thanks for the review.
</p>
TicketvbraunWed, 14 Dec 2016 23:15:56 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/15605#comment:27
https://trac.sagemath.org/ticket/15605#comment:27
<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/__1___2_3__evaluates_to_1</em> to <em>69f75eccbfeb3dbd370f382f6a4129a12a86d7da</em>
</li>
</ul>
TicketjdemeyerFri, 05 Oct 2018 15:26:29 GMTcommit deleted
https://trac.sagemath.org/ticket/15605#comment:28
https://trac.sagemath.org/ticket/15605#comment:28
<ul>
<li><strong>commit</strong>
<em>69f75eccbfeb3dbd370f382f6a4129a12a86d7da</em> deleted
</li>
</ul>
<p>
I disagree with the fix here. It seems to me that we really should catch more generally <code>(-a)^(even rational)</code> instead of only <code>(-1)^(even rational)</code>.
</p>
TicketjdemeyerFri, 05 Oct 2018 17:03:27 GMT
https://trac.sagemath.org/ticket/15605#comment:29
https://trac.sagemath.org/ticket/15605#comment:29
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/26414" title="defect: Various fixes to rational_power_parts() (closed: fixed)">#26414</a> for a follow-up.
</p>
Ticket