Possible new bug of solve()

47 views
Skip to first unread message

Emmanuel Charpentier

unread,
Oct 7, 2017, 2:19:55 PM10/7/17
to sage-support
Inspired by an as.sagemath question, I tried to solve a not-so-simple system, and found that Sagemath (8.1beta7) is currently unable to solve it :

sage: var("x,y,z,K")
(x, y, z, K)
sage: xi=3/4
sage: yi=0
sage: zi=0
sage: eq1=K==y^2*z/x^2
sage: eq2=xi+yi==x+y
sage: eq3=2*xi+yi+2*zi==2*x+y+2*z
sage: solve([eq1,eq2,eq3],[x,y,z])
[]


However, this system *is* solvable : one ca solve [eq2,eq3] for y and z, substitute the (only) solution in eq1 and solve it for x, which turns out to give three solutions (looking suspiciously close to the solution of a cubic) ; substituting each of these solutions in the solutions for y and z gives three (not-so-light) solutions for the system.

Trying to solve it with maxima invoked from sage also fails :

sage: %%maxima
....: display2d:false;
....: xi:3/4$
....: yi:0$
....: zi:0$
....: eq1:K=y^2*z/x^2$
....: eq2:xi+yi=x+y$
....: eq3:2*xi+y+2*zi=2*x+y+2*z$
....: sys:[eq1,eq2,eq3];
....: sol:solve(sys,[x,y,z])$
....: l:length(sol)$
....: l;
....:
false






[K=(y^2*z)/x^2,3/4=y+x,y+3/2=2*z+y+2*x]


0


Printing the value of sys shows that it is defined. Printing the length of the solution that this solution is indeed has length 0 (no solution) and that failing to print it is *not* an interprocess communication problem caused by a "too long" result.

However, when running the same Maxima program in the interpreter from the command line does give a solution (much more massive, by the way, that the one obtained manually). See enclosed source and output, obtained by :

cat ttstSolve.mac | sage --maxima > ttstSolve.out

Therefore, the problem seems to exist in Sage's interface to maxima, not in Maxima itself.

Perusing the list of symbolics tickets didn't allow me to recognize this bug. A cursory inspection of Maxima-related tickets gave no more results.

Questions :
1) Is this a new bug ?
2) Does it deserve a ticket ?

For what it's worth, Mathematica has no problem solving the system (in its native interface) and gives relatively lightweight solutions ; I failed to obtain solutions from fricas, giac and maple, as well as to get Mathematica's answer through its Sage interface.

HTH,

--
Emmanuel Charpentier


ttstSolve.mac
ttstSolve.out

Emmanuel Charpentier

unread,
Oct 8, 2017, 5:59:33 AM10/8/17
to sage-support
Another datapoint : Sympy seems to be able to (slowly) solve this system, via :

from sympy.solvers import solve as ssolve
ssol=ssolve([e.rhs()-e.lhs() for e in [eq1,eq2,eq3]],[x,y,z])


The output can be converted to Sage via:

Ssol=map(lambda S:map(lambda v,s:v==SR(repr(s)).simplify_full(), [x,y,z], S), ssol)

HTH,

--
Emmanuel Charpentier

Maarten Derickx

unread,
Oct 8, 2017, 8:26:00 AM10/8/17
to sage-support
It deserves a ticket, the main question is more whether the ticket should be a bug or an enhancement. But that is something that can still be changed later.

Emmanuel Charpentier

unread,
Oct 8, 2017, 2:53:55 PM10/8/17
to sage-support
I'd vote for a bug : since Maxima, used standalone,  *can* solve this system, not being able to use it correctly *is* a bug. Somewhere in our interface...

Emmanuel Charpentier

unread,
Oct 8, 2017, 2:59:26 PM10/8/17
to sage-support
Yet another datapoint : our interface to mathematica *can* be used to get a solution. The problem I got was that the result can't be translated back to Sage : Mathematica express its results as "rules" (e.g "var  -> expression" means "expression is a solution for var"). Manually translating these rules gives the Sage expression of the solutions.

HTH,

--
Emmanuel Charpentier

Emmanuel Charpentier

unread,
Oct 8, 2017, 3:22:40 PM10/8/17
to sage-support
This is now Trac#23992.

HTH,

--
Emmanuel Charpentier

Emmanuel Charpentier

unread,
Oct 8, 2017, 3:55:19 PM10/8/17
to sage-support
This is now Trac#23993, but deserves further discussion. I'll post something on sage-devel after thinking it out.

HTH,

--
Emmanuel Charpentier
Reply all
Reply to author
Forward
0 new messages