1 | initial version |

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.

2 | No.2 Revision |

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.

3 | No.3 Revision |

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.

4 | No.4 Revision |

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

*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
```

```
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.

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.