# Revision history [back]

I'm not sure what's causing the problem. eq1 shouldn't be blown away.

So since I can't help on that front, maybe we can approach it in another way. I think you're trying to check to see that the n that solve returns really is a solution, which is a good idea. solve has been known to return solutions which aren't really solutions in the past. [If I'm off-base, please disregard the following.]

But say test were something like

R 2/3 == R^2 4/9


or something, i.e. some yet-unsimplified expression but one that's true. Then your procedure would give a test3 of

18*R == 12*R^2


which isn't even a number, much less 0; it'll still be an expression. At best it might give 0 == 0. In your particular case, several options work for sanity checks:

bool(test)


which should return True,

(test.lhs()/test.rhs()).full_simplify()


which should give 1, and

(test.lhs()-test.rhs()).full_simplify()


which should give 0.

I'm not sure what's causing the problem. eq1 shouldn't be blown away.

So since I can't help on that front, maybe we can approach it in another way. I think you're trying to check to see that the n that solve returns really is a solution, which is a good idea. solve has been known to return solutions which aren't really solutions in the past. [If I'm off-base, please disregard the following.]

But say I'm not sure I know what your code is doing, though. If test were something like

R 2/3 == R^2 4/9


or something, i.e. some yet-unsimplified expression but one that's true. Then your procedure would give a test3 of

18*R == 12*R^2


which isn't even a number, much less 0; it'll still be an expression. At best it might give 0 == 0. In your particular case, several options work for sanity checks:

bool(test)


which should return True,

(test.lhs()/test.rhs()).full_simplify()


which should give 1, and

(test.lhs()-test.rhs()).full_simplify()


which should give 0.

I'm not sure what's causing the problem. eq1 shouldn't be blown away.

So since I can't help on that front, maybe we can approach it in another way. I think you're trying to check to see that the n that solve returns really is a solution, which is a good idea. solve has been known to return solutions which aren't really solutions in the past. [If I'm off-base, please disregard the following.]

I'm not sure I know what your code is doing, though. If I mean, if test were something like

R 2/3 == R^2 4/9


or something, i.e. some yet-unsimplified expression but one that's true. Then your procedure would give a test3 of

18*R == 12*R^2


which isn't even a number, much less 0; it'll still be an expression. At best it might give 0 == 0. In your particular case, several options work for sanity checks:

bool(test)


which should return True,

(test.lhs()/test.rhs()).full_simplify()


which should give 1, and

(test.lhs()-test.rhs()).full_simplify()


which should give 0.

I'm not sure what's causing the problem. eq1 shouldn't be blown away.

So since I can't help on that front, maybe we can approach it in another way. I think you're trying to check to see that the n that solve returns really is a solution, which is a good idea. solve has been known to return solutions which aren't really solutions in the past. [If I'm off-base, please disregard the following.]

I'm not sure I know what your code is doing, though. I mean, if test were something like

R 2/3 == R^2 4/9


or something, i.e. some yet-unsimplified expression but one that's true. Then true, then your procedure would give a test3 of

18*R == 12*R^2


which isn't even a number, much less 0; it'll still be an expression. At best it might give 0 == 0. In your particular case, several options work for sanity checks:

bool(test)


which should return True,

(test.lhs()/test.rhs()).full_simplify()


which should give 1, and

(test.lhs()-test.rhs()).full_simplify()


which should give 0.