MAINT: an easier way to make ranges from slices
Merge pull request #3117 from pv/ndimage-label-fix2

BUG: ndimage: fix swapped 64-bitness test
Merge pull request #3133 from pv/minimize-method-auto

ENH: optimize: choose method automatically in minimize
DOC: add 0.13.2 release notes.
MAINT: make ``python setup.py bdist_wheel`` work.
TST: [stats, discrete] tighten cdf-ppf tests
TST: [stats, discrete] tighten cdf-pmf tests
TST: [stats, discrete] remove non-running tests
TST: [stats, discrete] remove sample tests

They are too noisy: only work for decimal=0.
MAINT: deprecate simulated annealing
DOC: release notes
MAINT: use numpy decorator for deprecation
MAINT: deprecate the Anneal method with the minimize() framework
MAINT: typo
DOC: more anneal deprecation messages
Merge pull request #3139 from argriffing/deprecate-anneal

MAINT: optimize: deprecate simulated annealing
BUG: integrate: odeint handled the banded jacobian incorrectly.

When `col_deriv` is False, the C wrapper that calls the user's python code that
computes the jacobian matrix uses a macro, MATRIXC2F(jac, data, n, m), to copy
the data into the array that is used by the Fortran solver.  In that macro.
`jac` is the destination, `data` is the source, and `n` and `m` are the number
of rows and columns of the matrix.  The wrapper had the last two arguments
reversed.  In the case of a full jacobian, this did not matter, because the
matrix is square.  In the banded case, the number of rows and columns are not
the same.  This means that the only way to correctly use a banded jacobian was
to put the bands in the columns of the matrix, and use `col_deriv=True` so
MATRIXC2F was not used.  That would result in the data being in the correct
Fortran order, since the Fortran code expects the bands to be in the rows.

This commit fixes the use of MATRIXC2F.  Also, the docstring of odeint is
updated to reflect the correct API:  the bands should be put in the rows
of the matrix, not the columns (unless `col_deriv=True` is used).
BUG: special: comb returned incorrect result when given large np.int64 arguments.

When given `exact=True`, cast the arguments of `comb` to python ints to ensure
that the result is a python integer.  Otherwise a call such as
    comb(np.int64(70), np.int64(30), exact=True)
returns an incorrect result, because it does the calculations with np.int64s.
The true result is too large for a 64 bit integer.
Merge pull request #3146 from WarrenWeckesser/bug-misc-comb

BUG: special: comb returned incorrect result when given large np.int64 arguments
ENH: special: Add a ufunc to compute the Box-Cox transformation.