Opened 14 months ago

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

Reported by: Owned by: charpent major sage-9.5 symbolics pbruin N/A

### 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...

### comment:1 follow-up: ↓ 2 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

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: ↓ 7 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

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.