On python 3, I get TypeError: unorderable types: datetime.datetime() <= float(). nanmean gives me a similar error.

Python 2 lets you compare anything to anything else, and get a totally random result, which is why you don't get an error

Apologies, I forgot the slicing. I can replicate this behaviour on 3.5

Geez, seems that nanmin is just completely broken on the simplest input:

>>> arr = np.array([np.nan, 1], dtype=np.float64)
>>> np.nanmin(arr)
nan

There's a comment in there that says # Fast, but not safe for subclasses of ndarray. Seem to me that it should read # Fast, but not safe ever...

Edit: not on master

For the record, here is a somewhat hacky fix that is obviously unsavory for several reasons (fairly arbitrary cast, introduction of if, increased code):

def safe_nanfunc(data, nanfunc):
    if data.dtype == 'object':
        # cast to float
        data = np.ndarray.astype(data, dtype='f')
    return nanfunc(data)

In [1]: import numpy as np

In [2]: np.array([np.nan, 1], dtype=np.float64)
Out[2]: array([ nan,   1.])

In [3]: np.nanmin(np.array([np.nan, 1], dtype=np.float64))
Out[3]: 1.0

In [4]: np.nanmax(np.array([np.nan, 1], dtype=np.float64))
Out[4]: 1.0

wasn't a problem for me. I'm on Python 2.7.13 via conda macOS and

In [5]: np.__version__
Out[5]: '1.12.1'

It seems like unit tests should have caught this error, but regardless we have one above now! @eric-wieser if you agree this is a bug how long would it take to get this pushed into a minor version number if a fix can be found quickly?

I've filed a more specific issue at #8975

I doubt that there'll be a new release of 1.12 in the immediate future, since 1.13 is supposedly right round the corner - and the https://github.com/numpy/numpy/milestone/48 milestone is pretty empty right now.

@eric-wieser, I should note the speed to fix isn't a real problem but more of a curiosity for me. This is the type of thing I could likely fix but the unfortunate things is I'm under some severe time pressure right now and have a work around via safe_nanfunc for my current workflow.

Thanks @eric-wieser for the hints on how to fix the issue. It sounds like this might be fast to fix but my numpy dev environment is quite stale now. What is typically the timeline here, e.g., the process to typically get this type of thing fixed? I can't work on this now but may be able to make some time over the next 60 days or so.

I've split off the fmin thing into a new issue (#8975)

There's a quick fix to the nanfunctions which would be to change nanmin and friends to take the slow path for object arrays with a simply dtype == object check - I'd imagine you could submit that PR directly through the github web interface in around half an hour

A related bug: #6209

@pwolfram: Numpy 1.13 will now have a workaround for this, although the underlying bugs of #9009 and #8975 are still there