Opened 7 months ago
Last modified 5 weeks 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.4 |
Component: | symbolics | Keywords: | |
Cc: | pbruin | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
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") z sage: real(z).simplify() z sage: imag(z).simplify() 0 sage: with assuming(z,"complex"): real(z).simplify() realpart(z) sage: with assuming(z,"complex"): imag(z).simplify() imagpart(z)
As corollaries :
sage: var("a, b") (a, b) sage: (a*imag(z) + b*imag(z)).factor() 0 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() 0 sage: (a*z + b*z).factor().imag_part().simplify() 0
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)); ....: ....: complex 0 0 0
but :
sage: %%maxima ....: declare(z,complex); ....: imagpart(z); ....: imagpart(ratsimp(z)); ....: imagpart(factor(z)); ....: ....: done 'imagpart(z) 'imagpart(z) 'imagpart(z)
Filing this as blocker
, because this problem may lead to Sage silently returning mathematical nonsense...
Change History (8)
comment:1 follow-up: ↓ 2 Changed 7 months ago by
- Milestone changed from sage-9.2 to sage-9.3
comment:2 in reply to: ↑ 1 Changed 7 months ago by
comment:3 Changed 7 weeks ago by
- 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 6 weeks ago by
Well, has anyone filed it as an upstream bug?
comment:5 follow-up: ↓ 7 Changed 6 weeks ago by
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:
- Maxima seems to give different (much more complicated) answers for some definite integrals when the integration variable is declared to be complex.
- 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 6 weeks ago by
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 6 weeks ago by
Replying to gh-DaveWitteMorris:
- 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 5 weeks ago by
- 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.
either blocker for the 9.3 milestone, or critical only, please