Fixed the auxiliary.
Built a new file of test_kane2.py for testing the auxiliary speeds which are to calculate non-contributing forces when a system is added dependent speeds and coordinates.
I fixed Kane's bugs of auxiliary speeds.

When I used the auxiliary speeds of wheel-ground contact points
to obtain contact forces in physics.mechanics using kane's method
class, I confronted bugs which did not pop up correct forces. We
tried to suspect the _mat_inv_mul function, and then fixed dummy
symbols.
Cleaning up bugfix in physics.mech

The entire story:
So there were 2 main bugs here, and I'll go into detail for anyone not
familiar.

One was that when forming the auxiliary equations (bringing non-contributing
forces into evidence), the relationship between the dependent and auxiliary
speeds was not being considered, so it was almost assured any auxiliary
equations for constrained systems were going to be wrong. This was fixed,
and a test (which is pretty good, it tests lots of different expressions
generated by KanesMethod against expressions generated "by hand" in SymPy,
including the case with dependent/auxiliary speeds).

The other bug was a little less obvious. The method of the KanesMethod
class, _mat_inv_mull, was designed to invert a matrix and multiply it by
another matrix (or, sequentially solve a number of linear systems). It did
this symbolically - temporary symbols were generated for each element in
both matrices (unless the element was 0). This was done so that all of the
original elements would be substituted back in after the matrix operations
were done, in an attempt to prevent these matrix expressions from getting
out of hand. Now, if you look at the current (before this PR) code in
_mat_inv_mul, you see temporary symbols being generated (actually, a
temporary matrix full of temporary symbols):

temp1 = Matrix(r1, c1, lambda i, j: Symbol('x' + str(j + r1 * i)))

This produces symbols x0, x1, x2....
It should produce symbols x00, x01, x02... For non-square matrices the
symbols being produced were not all unique. So when the original quantities
were substituted back in, the wrong values were being subbed back in. This
is what the code looks like now; it actually has unique indices for each
element (although I think the r1 should go away).

temp1 = Matrix(r1, c1, lambda i, j: Symbol('x' + str(j) + str(r1 * i)))

For @stefenyin, in his bike code, he was getting 3 of the auxiliary forces
correct and 3 wrong when computing 6 reaction forces. In hindsight, I now
see that when computing 4 reaction forces, 3 were correct and 1 was wrong.
The reason for that is what was being passed to _mat_inv_mul were matrices
defining the relationships between the dependent and auxiliary speeds - a
3x3 and a 3x6 matrix. The 3x6 matrix is not square, and it ended up that the
first 3 columns of the output matrix were correct and the second 3 were not.
This then propagated to the calculation of Fr and Fr*, where the 1st 3
equations were correct and the second 3 were wrong. Finally, that led to
only half of the 6 reaction forces being correct. The order of auxiliary
speeds that @stefenyin chose is what led to the 3 rear-wheel contact forces
being correct and the front 3 being wrong. Currently, this fix does not
have a test. Testing it on the bicycle would be time prohibitive (a few
minutes). I originally decided not to write a test for this method because
the symbolic output was not always guaranteed to evaluate as identical
(when in fact it was), and I did not want to use numerical values.

Now, tests have been added for both of these bugs, which have been fixed.

-Gilbert & Stefen
Include SympifyError in __init__.py
Bidirectional facts between (non)negative, (non)positive, and (non)zero.

We already have, in sympy/core/assumptions.py:

real        == negative | zero | real
nonpositive == real & !positive
nonnegative == real & !negative
nonzero     == !zero

(Note that either nonnegative or nonpositive imply real.)

From these we can derive the following bidirectional facts between
negative, positive, zero and nonnegative, nonpositive, nonzero:

negative == nonpositive & nonzero
positive == nonnegative & nonzero
zero     == nonnegative & nonpositive

With the addition of the above bidirectional facts for negative, positive
and zero to sympy/core/assumptions.py we now correctly obtain the truth
value when setting some assumptions to False, for example:

>>> Symbol("x", positive=False, real=True).is_nonpositive
True
>>> Symbol("x", nonpositive=False, real=True).is_positive
True
Don't return None from inequalities.

Fixes issue 3564.
Implement is_bounded, is_finite, is_zero for Float().

Float always returns a Float, with the exception of Float('fnan')
which returns S.NaN. This is in contrast to e.g. Rational, which
returns instances of S.Zero, S.Infinity, and so on, given the args.
Thus we can have a zero float or a infinite float. This should be
reflected when we check the assumptions on these objects.

Fixes issue 2486.
More tests for inequalities.
Avoid chaining nontransitive comparisons. Use `and` instead.
More robust factor_nc().

If factor_nc() can't factor an expression, it should just return it
unchanged, not throw AssertionError.

In order to get a factorized result that matches the unfactorized
input expression in some cases involving powers of a Mul, we now
call powsimp() in addition to factor(). Thus it becomes necessary
to call expand(power_exp=True) when checking the result.

Fixes issue 3602.
Rely on .is_unbounded rather than comparing to S.(Negative)Infinity

Fixes a pypy failure:

dirac:~/git/sympy  $ cat my/pypy.py
from sympy import Float, S

print Float('+inf') in (S.Infinity,)
dirac:~/git/sympy  $ python my/pypy.py
True
dirac:~/git/sympy  $ pypy my/pypy.py
False
Rename _mexpand -> _pemexpand in sympy/core/exprtools.
Merge pull request #1727 from asmeurer/SympifyError

Include SympifyError in __init__.py
Merge pull request #1743 from jrioux/assumptions

Assumptions
Merge pull request #1760 from jrioux/factor

More robust factor_nc().
Merge pull request #1717 from StefenYin/fix_auxiliary

Fix auxiliary speeds bugs in physics.mechanics.