rolling requires pandas >= 0.18

[fujiisoup]

We need pandas >= 0.18 because dataframe.rolling is supported after 0.18.
But requirements in our setup.py says we need pandas >= 0.15.

Additionally, I noticed that in travis's CONDA_ENV=py27-min setup, our unit tests run with pandas == 0.20, though it might be intended to run with pandas == 0.15.

By conda remove scipy, pandas.0.15 is removed.
(Here is the travis log)

if [[ "$CONDA_ENV" == "py27-min" ]]; then conda remove scipy; fi
Fetching package metadata .........
Solving package specifications: .

Package plan for package removal in environment /home/travis/miniconda/envs/test_env:

The following packages will be REMOVED:

    pandas: 0.15.0-np19py27_0 defaults
    scipy:  0.17.1-np19py27_1 defaults

then in python setup.py install, pandas==0.20.3 is installed.

Searching for pandas>=0.15.0
Reading https://pypi.python.org/simple/pandas/
Downloading https://pypi.python.org/packages/ee/aa/90c06f249cf4408fa75135ad0df7d64c09cf74c9870733862491ed5f3a50/pandas-0.20.3.tar.gz#md5=4df858f28b4bf4fa07d9fbb7f2568173
Best match: pandas 0.20.3

[shoyer]

We should probably update our minimum required dependencies for the next release, both for pandas and numpy. Pandas 0.15 and numpy 1.7 are pretty old now.

Additionally, I noticed that in travis's CONDA_ENV=py27-min setup, our unit tests run with pandas == 0.20, though it might be intended to run with pandas == 0.15.

Yes, this is not intended!

[fujiisoup]

OK. I will send a PR to update the minimum version support.
To make our current logic work, pandas >= 0.18 is required.

How about numpy? pandas itself does not require newer numpy.
I'm wondering if we can require numpy > 1.11, many logics in npcompat can be cleaned up.

[shoyer]

pandas 0.18 came out in March 2016 (about 18 months ago by the time of our next release). I would be reluctant to require anything newer than NumPy 1.11, which also came out in March 2016.

I don't see removing functions from npcompat as particularly good justification on its own. But if there is new functionality that requires a newer NumPy, then that could be a good reason to require something newer (especially if it's hard to backport).

For example, if we required NumPy 1.13, then we could make use of NDArrayOperatorsMixin and __array_ufunc__. This might be worth it for the significant clean-up of our type casting hierarchy for arithmetic (e.g., as @dopplershift reported on his pain with in his scipy presentation).

[fujiisoup]

I don't see removing functions from npcompat as particularly good justification on its own.

Yes. Agreed.
The reason I propose numpy 1.11 is simply that conda recommends numpy >= 1.11 for pandas==0.18, though it also has a numpy==1.10 build.
(And I don't like the special treatment in our unit tests for numpy==1.10 bug related to np.quantile.)

Though I do not yet understand well about NDArrayOperatorsMixin, it sounds a good direction to keep a well-managed code.
But it might be a kind of heavy change and is better to be another issue?

I think to solve this particular issue, we can update supported oldest numpy to 1.11 (or 1.10).
If we could clean up casting-related things until next release, we further update it to 1.13.

[shoyer]

I'm +1 for requiring NumPy 1.11 and pandas 0.18.

Though I do not yet understand well about NDArrayOperatorsMixin, it sounds a good direction to keep a well-managed code.
But it might be a kind of heavy change and is better to be another issue?

Agreed!