3533: nfloat fix

A proper evaluation of an expression cannot be done by substituting
evaluated numbers into the expression as a result of precision issues.
Instead, numbers must be evaluated in groups, e.g. (sqrt(3) - sqrt(2)).n()
rather than sqrt(3).n() - sqrt(2).n(). Often this doesn't matter much,
but as the added test shows, it does matter.

evalf needs a serious overhaul to make this right, too, since if evalf
(instead of nfloat) is used on the added expression for this issue, the
same mistake occurs. This is because _matches_commutative deals with
args arg-wise (instead of in lumped args which are all numbers).

The way evalf should work, I believe, is:

1) expr.evalf()
  a) expr.is_number is False
    i) if subs given, then do the subs thing in evalf
    ii) else call to expr._eval_evalf (with n, not prec) to find the
       numbers and pass them back to evalf and replace them in the
       expr; if there is not expr._eval_evalf routine use the Mixin
       routine, changed to apply evalf to each of the args (rather
       than returning None as now).
  b) normal evalf when expr.is_number
3533: fix for Add/Mul evalf
simpler 3533 nfloat fix
use _aresame in xreplace test of equality

It is possible that A === B even though A and B are not structurally the
same, so the more strict _aresame() is used to test for exact equality.
Fix installation instructions for setupegg.py
Merge pull request #1681 from flacjacket/setup-docs

Fix installation instructions for setupegg.py
solve implicitly for anything except numbers

There is no reason to disallow solution of an equation for
a given object, so it is possible to isolate objects which are
not symbols as long as they are not numbers -- numbers should only
be themselves, so there should be nothing to solve for. Functions
like cos(1) are numbers and so are undefined functions like f(1)
but the latter are allowed since they don't evaluate to a number.
supply non-numeric objects as symbols if necessary
add note about implicit solving

Although solving for numbers 1, cos(1 + sqrt(2)) could be added,
this has not been added at this time. To do this, the user will
have to handle the substitution on their own.

Part of the reason this was avoided was because if expressions
are given that are themselves numbers, then trying to rearrange
for a number in that expression can only be done if the expression
itself is 0 -- if it's not then any inferences made from it are
invalid.  One has to watch for -1 that is hiding in all subtractions, too.

e.g. if eqs = Tuple(4 - sqrt(2), sqrt(2)/3 + 1)
>>> eqs = Tuple(4 - sqrt(2), sqrt(2)/3 + 1)
>>> eqs.subs([(1,a),(4,b)])
(-sqrt(2)*a + b, a + sqrt(2)/3)
>>> solve(_)
{b: -2/3, a: -sqrt(2)/3}

but compare to the solution after masing off the -1

>>> solve(eqs.subs(-1, Symbol('-1')).subs([(1,a),(4,b)]), a, b)
{b: -sqrt(2)*-1, a: sqrt(2)/(3*-1)}
>>> Dict(_).subs(Symbol('-1'), -1)
{a: -sqrt(2)/3, b: sqrt(2)}
Merge pull request #1679 from smichr/3533

3533
solve can solve for any expression -- no checking
Merge pull request #1682 from smichr/solve

solve implicitly for anything
1784: use signsimp in match
1220: handle longer pattern first in _matches_commutative
679: try Pow->Mul->Add in match
784: try collect in match
3004: watch for matching -arg in _combine_inverse
record expressions seen in match_commutative
3539a: match fails if pattern has extra syms

The "extra syms" are symbols in the exact part of a pattern. If the
symbols are combined with Wilds (as shown in the added test) then
the match continues.
3539: do not let Add match become more complex