Not related to this PR: that numpy prints complex numbers as
9.90012467+0. j looks annoying because that's not copypasteable
any more. This maybe is a numpy bug...

I agree, it doesn't look nice. The link in my first comment suggests that one can use a legacy print mode. Perhaps that's the way forward for the time being? I'm not sure how one would go about setting that mode, presumably in ref_guide.py?

There's something going on with that specific example in tutorial/linalg.rst. The output is different on the travisCI box vs my OSX machine.

There's also an unrelated stats test failing on Appveyor, test_weightedtau.

       # NaNs
       x = [12, 2, 1, 12, 2]
       y = [1, 4, 7, 1, np.nan]
>       tau, p_value = stats.weightedtau(x, y)
p_value    = nan
tau        = nan
x          = [12, 2, 1, 12, 2]
y          = [1, 4, 7, 1, nan]
C:\Python36-x64\lib\site-packages\scipy\stats\tests\test_stats.py:792: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
C:\Python36-x64\lib\site-packages\scipy\stats\stats.py:3713: in weightedtau
   if np.isnan(np.min(y)):
C:\Python36-x64\lib\site-packages\numpy\core\fromnumeric.py:2420: in amin
   out=out, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
a = array([ 1.,  4.,  7.,  1., nan]), axis = None, out = None, keepdims = False
   def _amin(a, axis=None, out=None, keepdims=False):
>       return umr_minimum(a, axis, None, out, keepdims)
E       RuntimeWarning: invalid value encountered in reduce
a          = array([ 1.,  4.,  7.,  1., nan])
axis       = None
keepdims   = False
out        = None
C:\Python36-x64\lib\site-packages\numpy\core\_methods.py:29: RuntimeWarning
1 failed, 13315 passed, 1356 skipped, 138 xfailed, 9 xpassed in 528.75 seconds 
Command exited with code 1

I don't have access to a windows box but it looks like

np.isnan(np.min([1., 4., 7., 1., np.nan]))

is an issue. Not sure of the ultimate cause.

see numpy/numpy#10355. @pv, I think you posted on there that we should hold off on this merge until the printing gets fixed. Unfortunately that'll mean that our CI is out of action until the next numpy release.

The ultimate cause is that np.min throws a warning if a real number and np.nan are compared. Conceptually, this seems fine.

W.r.t stats.weightedtau I wonder why is it only showing up on a subset of the Windows tests?

In stats.weightedtau:

NaNs are considered the smallest possible score.

The documentation for np.amin says:

NaN values are propagated, that is if at least one item is NaN, the corresponding min value will be NaN as well.

It doesn't say that warnings are raised if NaN's are in the array. On my machine:

>>> import numpy as np
>>> np.min([1,2,np.nan])
nan
>>> with np.errstate(all='raise'):
...     np.min([1,2, np.nan])
nan

The code in L3711 to L3714 contains the lines:

    if np.isnan(np.min(y)):
            y = _toint64(y)

perhaps this should be:

if np.any(np.isnan(y)):
        y = _toint64(y)

What happens with this on linux?

Have a look at this weird behaviour I've just seen in my interpreter:

Python 3.6.3 |Anaconda, Inc.| (default, Nov  3 2017, 12:34:11) 
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.min([1,2,np.nan])
nan
>>> with np.errstate(all='raise'):
...     np.min([1,2, np.nan])
... 
nan
>>> np.min([1, np.nan])
/Users/andrew/miniconda3/envs/dev3/lib/python3.6/site-packages/numpy/core/_methods.py:29: RuntimeWarning: invalid value encountered in reduce
  return umr_minimum(a, axis, None, out, keepdims)
nan
>>> np.min([1, np.nan])
nan

i.e. why does the warning only appear once?

@xoviat it appears I edited your comment by mistake, sorry.

The behavior appears to be deterministic on my windows machine; it always gives the warning (the results are the same). Do you think that, conceptually, there should be a warning?

If so, then the test would appear to be broken.

I think the documentation and actual behaviour should tally.

NaN values are propagated, that is if at least one item is NaN, the corresponding min value will be NaN as well.

This doesn't indicate that a warning will result. I have just done the following in a clean conda env (3.6.2) with numpy installed via pip. There were no warnings!

>>> import numpy as np
>>> np.version.version
'1.14.0'
>>> np.min([1., 2., 3., 4., np.nan])
nan
>>> np.min([1., 2., 3., np.nan, 4.])
nan
>>> np.min([1., 2., np.nan, 3., 4.])
nan
>>> np.min([1., np.nan, 2., 3., 4.])
nan
>>> np.min([np.nan, 1., 2., 3., 4.])
nan
>>> np.min([np.nan, 1.])
nan
>>> np.min([np.nan, 1., np.nan])
nan
>>> np.min([1., np.nan])
nan
>>> np.seterr(all='raise')
{'divide': 'warn', 'over': 'warn', 'under': 'ignore', 'invalid': 'warn'}
>>> np.min([1., np.nan])
nan
>>> np.min([np.nan, 1.])
nan
>>> np.min([np.nan, 1., 2., 3., 4.])
nan
>>> np.min([np.nan, 1., 2., 3., 4.])
nan

The weird behaviour in my previous post was that

>>> np.min([1,2,np.nan])
nan
>>> with np.errstate(all='raise'):
...     np.min([1,2, np.nan])
... 
nan

didn't give any warnings, but then when I subsequently typed np.min([1., np.nan]), there was a warning. Why should the length of the array change behaviour?

Something isn't working reproducibly across numpy installs.

LGTM modulo a need for a rebase.

Refguide-checker should be able to handle some of these, but that needs someone to have a look. I probably will at some point, no ETA though.

Rebased the PR, so we'll see what happens. AFAICT the doctesting is being done on py35, with pypi numpy?

Whilst looking at the travis config am I right in understanding that we test the numpy master branch in a py27 environment? We should probably move that to 3.x.

We obviously wouldn't have picked the numpy issues up with the doctesting unless we were targeting the master branch, rather than the released wheel.

A few minor nits needed changing.
What's the received wisdom on the doctest - we're obviously looking for correct numerical + object behaviour, but these tests are seem to be picky about the number of spaces, etc.

While the default doctest behavior is very picky about whitespace, our test checker tries to select numeric entities and np.assert_allclose them, where it can. It just fails to find arrays nested too deep into other objects, and falls back to vanilla doctest. Which is arguably a deficiency in our doctester.

I'd suggest to both fix the nits so that our examples match what numpy outputs out of the box, and improve the doctester (in a separate PR).

So if the changes I've made here finally work, then this should be mergeable. Currently PR's will have at least one fail because of the doctest errors fixed in this PR.

Thanks @andyfaff; will be nice to have the CIs green again.