1400: cse is deterministic and ignores singleton expressions

deterministic

Since cse relies on making substitutions at the very beginning
in the preprocessing, and substitution is an order-sensitive proceedure,
it was necessary to sort the Adds that are being identified in that
process.

The use of default_sort_key from the traversal was removed. This is not
needed in the sub-expression identification stage. The insert method
that sought to keep the expressions in order was also removed. The
default_sort_key applied in one branch of the expression tree in one
of the expressions given to cse doesn't guarantee that another expression
with the same key (as was defined in the insert method) will be in a
deterministic order -- the tie would not be broken.

So now all the expressions are collected however they come from the
tree and are assembled in set. These (and the Add and Mul terms that
are handled individually) are sorted with the lazyDSU sort which seeks
to put the items in some canonical order. This is the source, then,
of determinism in the method.

In addition, expressions that are only used once are no longer reported
in the returned expressions, e.g. whereas one might have gotten
[[(x0, x+1)], [cos(x0)]] perviously, now [[], [cos(x + 1)]] will be
returned.

The insert method used to keep the expressions arranged in a particular
order was removed since more than this is
move sorting functions to compatibility

In addition, the traversals are capable of a lazy sort
which should be faster when ties can be broken with a simple
count_ops comparison.
3460: watch for oo in ndiv

By watching for extractable negatives at the outset, the
problem can be circumvented. I'm not sure where the infinities
are being generated by such a simple substitution as
(-12*x).subs(-x,1).
3459: watch for nc during expansion

In addition, if something has a polar=False assumption, this doesn't
mean that it is a negative number, so None is returned if polar is False
in the sifting of arguments.

Tests were added to bring the coverage of Pow._eval_expand_power_base to
100%.
import cleanup and docstring example added
fuzzy_not with other fuzzy_foo; tweak fuzzy_bool

There were two fuzzy_nots; now there is one and all the fuzzy_foos
are in core.logic.

fuzzy_bool was optimized a bit to take advantage of the
current behavior of equality and is-checking being faster
than calculating the bool:

from timeit import timeit as t
>>> t('1 == True')
0.17005395889282227
>>> t('1 is True')
0.12167119979858398
>>> t('bool(1)')
0.3265230655670166
>>> t('bool(True)')
0.3634920120239258
args_cnc has flag to not split -1 from Number
3462: unification of _eval_power and _eval_expand_power_base

This is something that was sorely needed: much code was being duplicated
(incompletely) between Pow._eval_power and Mul._eval_expand_power_base.
The best of both has now been consolidated under Mul so it is now much
easier to maintain and to see what is part of auto-expansion in Pow and
what is not.

While working on this I realized that powers that weren't strictly Rational
could still allow separation of the bases and made that change in
simplify, too.

The test that was changed in arit was tested at Wolfram Alpha:
http://tinyurl.com/8vsbhzs
consolidate expand tests
fix Mul.flatten

It was assumed that only things like 2*sqrt(3) might be encountered;
with the changes that have been made, it is now possible to get
things that have more terms, so now provision is made for that.
fix powdenest test

fix meijerint test for simpler expression
pyflakes minor cleanups
add permutations to iterables imports
determinism for trigsimp; use small_first_keys in solve

Now that cse is deterministic, trigsimp (which used it) is, too.
deterministic risch algorithm

In the places where atoms were being iterated over, a canonically
ordered list is being used instead, now, which should give
system invariant results. In addition, only the new atoms
that haven't been seen before are being filtered in a
common function `update` that appears just before the while-loop.
fix reshape
increase coverage of compatibility
modify quick_sort to call lazyDSU_sort

lazyDSU_sort and quick_sort are basically doing the same thing, so
now quick_sort is used throughout SymPy and it is just a wrapper to
lazyDSU_sort. A new convenience key (hash_small_first_keys) was added
which uses the hash as the primary key, followed by count_ops (small
first) and the default_sort_key. This is the key that is selected
by default for quick_sort; None selects small_first_keys; and False
doesn't do anything but apply default_sort_keys -- it will be the
slowest of the 3 default sorting options. Custom keys can be provided
but the warn flag will always be True. So when you see quick_sort
being used you know that it will be quick (using only the keys necessary
to break ties) and there will be no ties -- a canonical result will
be obtained.