Opened 14 months ago

Last modified 3 months ago

#30793 new defect

Sage may ignore the imaginary part of variables not explicitly declared complex

Reported by: charpent Owned by:
Priority: major Milestone: sage-9.5
Component: symbolics Keywords:
Cc: pbruin Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges


Seen in this ask.sagemapt question, discussed in sage-devel :

Sage seems to assume that a not otherwise specified symbolic variable is real :

sage: var("z")
sage: real(z).simplify()
sage: imag(z).simplify()
sage: with assuming(z,"complex"): real(z).simplify()
sage: with assuming(z,"complex"): imag(z).simplify()

As corollaries :

sage: var("a, b")
(a, b)
sage: (a*imag(z) + b*imag(z)).factor()
sage: (a*z + b*z).factor().imag_part()
imag_part(z)*real_part(a) + imag_part(z)*real_part(b) + imag_part(a)*real_part(z) + imag_part(b)*real_part(z)
sage: (a*z + b*z).factor().imag_part().factor()
sage: (a*z + b*z).factor().imag_part().simplify()

but :

sage: with assuming(z,"complex"): (a*z + b*z).factor().imag_part().factor()
(a + b)*imagpart(z)
sage: with assuming(z,"complex"): (a*z + b*z).factor().imag_part().simplify()
a*imagpart(z) + b*imagpart(z)

Maxima has the same problem : in Sage's maxima :

sage: %%maxima
....: domain;
....: imagpart(z);
....: imagpart(ratsimp(z));
....: imagpart(factor(z));

but :

sage: %%maxima
....: declare(z,complex);
....: imagpart(z);
....: imagpart(ratsimp(z));
....: imagpart(factor(z));

Filing this as blocker, because this problem may lead to Sage silently returning mathematical nonsense...

Change History (9)

comment:1 follow-up: Changed 14 months ago by chapoton

  • Milestone changed from sage-9.2 to sage-9.3

either blocker for the 9.3 milestone, or critical only, please

comment:2 in reply to: ↑ 1 Changed 14 months ago by charpent

Replying to chapoton:

either blocker for the 9.3 milestone, or critical only, please

Okay. Will do that also for #30688.

comment:3 Changed 8 months ago by vbraun

  • Priority changed from blocker to major

De facto this can't be a blocker if noone is enough invested to work on it. Probably should be fixed on the maxima side first, too.

comment:4 Changed 8 months ago by mkoeppe

Well, has anyone filed it as an upstream bug?

comment:5 follow-up: Changed 8 months ago by gh-DaveWitteMorris

This was reported upstream on #6862. The maxima developers deny that it is a bug, and I agree with them, because the maxima documentation makes it clear that merely setting domain:complex will not make individual variables default to being complex. If sage wants variables to be complex, then it should declare them that way.

However, I tried this a couple of months ago (just by making a minor modification to SR.symbol) and got lots of doctest failures. The two main problems were:

  1. Maxima seems to give different (much more complicated) answers for some definite integrals when the integration variable is declared to be complex.
  2. There were also a lot of failures in manifolds, so perhaps that code is assuming that the variables are real.

The problem has been around a long time, and I don't think this can be fixed in time for 9.3. We should try to do something for 9.4, but I think it will require serious work.

Maybe this ticket should be closed as a duplicate of #6862.

comment:6 Changed 8 months ago by mkoeppe

Thanks for the analysis! +1 for consolidating the two tickets, closing one of them, and moving the remaining one to milestone 9.4.

comment:7 in reply to: ↑ 5 Changed 8 months ago by nbruin

Replying to gh-DaveWitteMorris:

  1. Maxima seems to give different (much more complicated) answers for some definite integrals when the integration variable is declared to be complex.

That's to be expected. Complex path integrals are generally path-dependent, so just specifying the end points of the path doesn't tell the whole story. Much of the integration machinery will normally be assuming real variables. This is one reason to *not* assume complex variables by default.

The main problem found on #6862 is the present incompatibility between pynac's and maxima's default. With this information, perhaps it would be worth seeing how bad inserting a default assume(<var>,"real") so that pynac at least agrees with maxima. If that leads to significantly less doctests, perhaps that's a preferable direction to resolve the mismatch.

comment:8 Changed 8 months ago by mkoeppe

  • Milestone changed from sage-9.3 to sage-9.4

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review.

comment:9 Changed 3 months ago by mkoeppe

  • Milestone changed from sage-9.4 to sage-9.5
Note: See TracTickets for help on using tickets.