CODEWITHSUNDEEP
sympy
jacob
jacob

Reputation: 899

sympy solve gives wrong result

sympy.solve() seems to give me a wrong result. There are known problems with inequalities, e.g. http://code.google.com/p/sympy/issues/detail?id=3244 but this is simple enough that it should work:

 import sympy
    from sympy.abc import x, u, s
    t1 = x*(1 - x)/(1 - s*x)
    t2 = u*x + (1-s)*(1 - u)*x*(1 - x)/(1 - s*x)
    sympy.solve(t1-t2,x)

is giving me 3 solutions. There should be only two, the first one is wrong. Is this a bug or am I making a mistake somewhere?

Upvotes: 3

Views: 340

Answers (1)

asmeurer
asmeurer

Reputation: 91490

This has been fixed in the development version of SymPy (and in 0.7.2, which will be released in about a week). It now gives [0, s*(u - 1)/(2*s*u - s - u)].

So, to answer your question, yes, it was a bug, and it was fixed.

Regarding what went wrong before, I used git bisect to narrow down the commit that fixed the problem. That commit just changed the way that one of the fundamental simplification algorithms in SymPy, as_numer_denom, works. So I guess what happened is that the result in some intermediate operation came out simple enough that solve() was able to recognize that the bad solution is just 1/s (assuming the square root denests). solve() does check the solutions it finds by pluggin them back in, but if they are too complicated, it won't be able to tell if they are bogus.

Probably actually what happened, now that I look a little closer is that just (t1 - t2).as_numer_denom()[0], which solve uses (because the zeros of an expression are just the zeros of the numerator), in 0.7.2 only has degree 2 in x, whereas in 0.7.1 it had degree 3. The bogus solution came from this "false zero" (meaning it was also a zero of the denominator), and as I noted, it was too complicated for solve to notice it as such.

That's the best I can say without really digging into the code deeper.

Upvotes: 2

Related Questions