http://stackoverflow.com/questions/43659827/numpy-error-when-specifying-axis-in-nanmax-while-nansum-works-an-the-same-case/43660147#43660147

There is an answer with three downvotes that explains why this is not a bug. Happy realisation :)

Nansum and Nanmax are not coded in the same fashion , a detailed explanation is available on the post. It's not an axis issue to begin with...

So, ideally this breaks down into:

• We need a O->? loop for the np.isnan ufunc (ENH: Add a np.isnan loop for the object dtype (and possible isfinite, ...) #9009)
• We need to correct the OO->? loop for fmin and fmax (BUG: np.fmin behaves differently on object arrays #8975)

As a quick workaround, we should just not allow object arrays to take that special case branch

Yes, explicity type cast to float.
Nanmax does in the beginning of it's source code , the following :
res = np.fmax.reduce(a, axis=axis, out=out, **kwargs)
if np.isnan(res).any():

The np.isnan() fails on object type columns.

@Satyadev592: Not the right fix. np.fmax.reduce is broken on object columns too.

This is essentially a different manifestation of the problem at #8974, and the quick fix to numpy would be as described there. This is absolutely a bug in numpy.

@Satyadev592:

Yes, fmax is broken on object columns as well. But the assumption that axis is the reason for this is wrong. It's purely the data type of the column. The code works with row wise axis just because it coerces the data type to float (purely because of the dataset here)

The code example at the top of this page directly contradicts that claim, does it not?

The problem manifests itself only when all of the following are true: axis is specified, dtype is object, and input is 2d or higher

Take a numpy array with only string values and try the nanmax on either axis. It still pops an error. The error this time is something to do with the fmax, dig a bit deeper , it's got something to do with numpy not having good support for the object datatype. If this is a bug , then a bug for each numpy function should be created for lack of support for object datatypes. This particular problem makes you think axis is a reason while it has nothing to do with the problem.

Also shifting an explicit casting to float inside source code is probably not a good idea. Numpy does not seem to be designed for object types [Well established i think]

Also , the documentation for np.nanmax does not seem to indicate support for object data type (general norm from whatever i have gathered about numpy) :

Take a numpy array with only string values

Strings are an entirely different beast, and have little to do with the object dtype. The problem there is that flexible types (np.bytes_, np.void, np.unicode_) are not supported by the ufunc system, due to having variable sizes. object arrays are perfectly supported by ufuncs - it just so happens that we don't have an implementation of isnan for them.

If this is a bug , then a bug for each numpy function should be created for lack of support for object datatypes.

Absolutely. If you can find numpy functions that fail with object arrays, where it would make sense for them not to, then either:

• Their documentation should be updated to warn about this
• They should be fixed so that they do.

This issue would be fixed by #6320 (I just tested the example).

[1]: a = np.array([[1.0, 2.0], [3.0, 4.0]], dtype=object)
[2]: np.nanmax(a, axis=0)
array([3.0, 4.0], dtype=object)
[3]: x = np.array([1, np.nan])
[4]: np.fmin.reduce(x)
1.0
[5]: np.fmin.reduce(x.astype(object))
1.0

Closing, all the examples work correctly (including the last one np.fmin.reduce(x.astype(object)) which returns nan). Please reopen if I misunderstood.

The bug here is that the case you mention should not return nan

However that's covered in gh-8975, so fine to close this

Closed by gh-9013