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 Le dimanche 8 octobre 2017 11:59:33 UTC+2, Emmanuel Charpentier a écrit : > > 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 > > Le samedi 7 octobre 2017 20:19:55 UTC+2, Emmanuel Charpentier a écrit : >> >> Inspired by an as.sagemath question >> <https://ask.sagemath.org/question/39040/solving-a-system-of-equations-small-known-number-hinders-the-solution/>, >> >> 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 <https://trac.sagemath.org/wiki/symbolics> 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 >> >> >> -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
