(Possible) bug in solving a simple complex equation.

[Emmanuel Charpentier]

Consider :

sage: reset() sage: z=var("z") sage: Eq=(3+4*I)^2-2*(z.conjugate())==z ; Eq -2*conjugate(z) + 24*I - 7 == z sage: Sol=solve(Eq, z) ; Sol [z == (8*I - 7/3)] sage: Eq.subs(Sol[0]) (40*I - 7/3) == (8*I - 7/3) sage: bool(Eq.subs(Sol[0])) False

which annoys me immensely. It reeks of conjugate() error, which, AFAICT is ginac territory…

However :

sage: E2=(Eq.lhs()-Eq.rhs()).subs(z=x+I*y) ; E2 -3*x + I*y + 24*I - 7 sage: S2=solve([E2.real(), E2.imag()], [x, y]) ; S2 [[x == (-7/3), y == -24]] sage: E2.subs(S2[0]) 0 sage: Eq.subs(z==x+I*y).subs(S2[0]) (-24*I - 7/3) == (-24*I - 7/3)

This failure to solve a simple equation on complexes is troubling. Re-reading myself did not led me to “obvious” problems.

Does this deserve a critical ticket ?

BTW, there is currently no free alternative :

sage: solve(Eq, z, algorithm="sympy") ConditionSet(z, Eq(-z - 2*conjugate(z) - 7 + 24*I, 0), Complexes) sage: solve(Eq, z, algorithm="giac") Warning, the test a==b is performed by checking that the internal representation of regroup(a-b) is not 0. Therefore a==b may return false even if a and b are mathematically equal, if they have different internal representations. You can explicitly call a simplification function like simplify(a-b)==0 to avoid this. Warning, argument is not an equation, solving false=0 [z] sage: solve(Eq, z, algorithm="fricas") [z == (8*I - 7/3)] sage: solve(Eq, z, algorithm="maxima") [z == (8*I - 7/3)] sage: [[u[1].sage()==u[2].sage() for u in s] for s in mathematica.Solve(Eq, z)] [[z == (-24*I - 7/3)]]

HTH,

​