Taking the real part of a sum of exponentials with imaginary exponents gives wrong result

[sagetrac-inaki]

In sage 4.8 the following computation gives 1/2, while the right result is -3/2:

sage: a = exp(i*2*pi/3)
sage: b = exp(i*pi/3)
sage: c = 2*a-b
sage: c.real()
1/2

Doing the computation numerically gives the right result:

sage: N(c).real()
-1.50000000000000

and asking maxima directly also works:

sage: (c.maxima_methods().rectform()).real()
-3/2

This is sage 4.8 running on Fedora 16, linux 3.1.0-7.fc16.x86_64 SMP.

Depends on #18362

Upstream: Fixed upstream, in a later stable release.

Component: symbolics

Author: Ralf Stephan

Branch/Commit: 410bab7

Reviewer: Travis Scrimshaw

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

[burcin]

comment:1

Thanks for the report! This is a bug in Pynac. I opened a ticket here:

http://hg.pynac.org/pynac/issue/15/wrong-result-from-real-part

[kcrisman]

comment:6

This gets really weird, actually.

sage: a.real()
-1/2
sage: b.real()
1/2
sage: (a-b).real() # good
-1
sage: (a-2*b).real() # good
-3/2
sage: (a-3*b).real()  # ho-hum
-2
sage: (2*a-b).real() # yikes
1/2
sage: (3*a-b).real()  # what?
3/4
sage: (4*a-b).real()  # consistent...
1
sage: (5*a-b).real()  # ?!?!?
5/4
sage: (-a-b).real()  # seeing but not believing
-1/4
sage: (-2*a-b).real()
-1/2
sage: (-3*a-b).real()
-3/4
sage: (2*a).real()  # okay
-1
sage: (2*a+b).real()  #  okay
-1/2
sage: (3*a+b).real()
-1
sage: (4*a+b).real()
-3/2

This is consistent with Pynac somehow thinking that a.real()==1/4 when preceded by a positive constant and -1/4 when given a negative constant. But only when part of a sum including -b, with +b it's fine.

I tried to figure out what it was but so far no luck.

[rwst]

comment:7

Actually and surprisingly what's happening is that the simplified values of the exp expressions (1/2 and -1/2) and their coefficients are all multiplied together on final evaluation:

sage: (4*exp(i*pi/3)-4*exp(i*2*pi/3)).real_part()
4
sage: (6*exp(i*pi/3)-6*exp(i*2*pi/3)).real_part()
9

This is evident in the GiNaC source, this line(https://github.com/pynac/pynac/blob/master/ginac/add.cpp#L432):

    oc = oc.mul(ex_to<numeric>(j->rest)).mul(ex_to<numeric>(j->coeff));

is so rarely executed that e.g. only three doctests in symbolic/ touch it but don't trigger the bug because the expressions are too short.

The fix will be in Pynac-0.3.7.

[rwst]

Dependencies: pynac-0.3.7

[rwst]

Upstream: Fixed upstream, in a later stable release.

[rwst]

Branch: u/rws/taking_the_real_part_of_a_sum_of_exponentials_with_imaginary_exponents_gives_wrong_result

[rwst]

New commits:

23892cb	18362: upgrade to pynac-0.3.7; fix one changed doctest result
410bab7	12807: doctest

[rwst]

Commit: 410bab7

[rwst]

Author: Ralf Stephan

[rwst]

Changed dependencies from pynac-0.3.7 to #18362

[tscrim]

comment:10

LGTM.

[tscrim]

Reviewer: Travis Scrimshaw

[vbraun]

Changed branch from u/rws/taking_the_real_part_of_a_sum_of_exponentials_with_imaginary_exponents_gives_wrong_result to 410bab7