derivatives of Max() and Min() using Heaviside()

modified:   sympy/functions/elementary/miscellaneous.py
modified:   sympy/functions/elementary/tests/test_miscellaneous.py

* added fdiff for Min() and Max()
* added diff Min() and Max()
* implement simple tests of Max().diff and Min().diff
* use ArgumentIndexError for assertions in fdiff
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.
Add degree_offset option to heurisch(), for testing diff degree bounds

See issue 2606

Conflicts:
	sympy/integrals/heurisch.py
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
convert factorials to gamma-function format
adding factorial test case
be more explicit with the rewrite operation
stripping trailing whitespace
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.
adding negative number test case
only rewrite for positive z0
Make RootOf.n() return the correct root

The way RootOf.n() works is the following: RootOf contains the interval (a, b)
where the (only) root is (as symbolically represented by RootOf). We then take
the center of the interval as an initial estimate for findroot() from mpmath.
However, sometimes findroot() finds a root that is not from the interval (a,
b), because the initial estimate was too far, and findroot() found a different
root (from some other interval) instead.

The solution is to check, that the findroot()'s result is from the interval
(a, b) and if it is not, just keep refining the interval. Eventually the
initial estimate will be close enough, so that findroot() converges to the
correct root.

Test (that previously failed and now works) added.
RootOf.eval_rational() implemented

Test added.
Add Gauss-Legendre and Gauss-Laguerre quadratures

Added gauss_legendre() and gauss_laguerre() functions and tests for calculating
the quadrature points and weights. The functions work for any order and any
precision.