<p dir="auto">This was the underlying cause of a problem reported on stackoverflow: <a href="http://stackoverflow.com/questions/43659827/numpy-error-when-specifying-axis-in-nanmax-while-nansum-works-an-the-same-case" rel="nofollow">http://stackoverflow.com/questions/43659827/numpy-error-when-specifying-axis-in-nanmax-while-nansum-works-an-the-same-case</a></p>
<p dir="auto">The error is raised when applying <code class="notranslate">nanmax()</code> or <code class="notranslate">nanmin()</code> to an array with object data type and specifying an axis.</p>
<p dir="auto">Here's the example from my answer:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="In [2]: import numpy as np

In [3]: np.__version__
Out[3]: '1.13.0.dev0+bca7922'

In [4]: a = np.array([[1.0, 2.0], [3.0, 4.0]], dtype=object)

In [5]: np.nanmax(a, axis=0)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
&lt;ipython-input-5-a020f98a2536&gt; in &lt;module&gt;()
----&gt; 1 np.nanmax(a, axis=0)

/Users/warren/miniconda3numpy/lib/python3.5/site-packages/numpy-1.13.0.dev0+bca7922-py3.5-macosx-10.6-x86_64.egg/numpy/lib/nanfunctions.py in nanmax(a, axis, out, keepdims)
    343         # Fast, but not safe for subclasses of ndarray
    344         res = np.fmax.reduce(a, axis=axis, out=out, **kwargs)
--&gt; 345         if np.isnan(res).any():
    346             warnings.warn(&quot;All-NaN slice encountered&quot;, RuntimeWarning, stacklevel=2)
    347     else:

TypeError: ufunc 'isnan' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''"><pre class="notranslate"><code class="notranslate">In [2]: import numpy as np

In [3]: np.__version__
Out[3]: '1.13.0.dev0+bca7922'

In [4]: a = np.array([[1.0, 2.0], [3.0, 4.0]], dtype=object)

In [5]: np.nanmax(a, axis=0)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
&lt;ipython-input-5-a020f98a2536&gt; in &lt;module&gt;()
----&gt; 1 np.nanmax(a, axis=0)

/Users/warren/miniconda3numpy/lib/python3.5/site-packages/numpy-1.13.0.dev0+bca7922-py3.5-macosx-10.6-x86_64.egg/numpy/lib/nanfunctions.py in nanmax(a, axis, out, keepdims)
    343         # Fast, but not safe for subclasses of ndarray
    344         res = np.fmax.reduce(a, axis=axis, out=out, **kwargs)
--&gt; 345         if np.isnan(res).any():
    346             warnings.warn("All-NaN slice encountered", RuntimeWarning, stacklevel=2)
    347     else:

TypeError: ufunc 'isnan' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
</code></pre></div>
<p dir="auto">There is no error when the axis is not given:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="In [6]: np.nanmax(a)
Out[6]: 4.0"><pre class="notranslate"><code class="notranslate">In [6]: np.nanmax(a)
Out[6]: 4.0
</code></pre></div>
<p dir="auto"><code class="notranslate">nansum()</code> handles the axis without an error:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="In [7]: np.nansum(a, axis=0)
Out[7]: array([4.0, 6.0], dtype=object)"><pre class="notranslate"><code class="notranslate">In [7]: np.nansum(a, axis=0)
Out[7]: array([4.0, 6.0], dtype=object)
</code></pre></div>
<p dir="auto">There are several other issues involving the nan-functions and object arrays, but I couldn't tell if  this issue is a duplicate.  Sorry for the noise if it is.</p>
<p dir="auto">The documentation for numpy.dual states "Aliases for functions which may be accelerated by Scipy." One of the functions supported is cholesky. One would assume (I did) that the results will be the same regardless of whether scipy is installed or not; only the execution time might vary.</p>
<p dir="auto">However, the implementation in numpy and scipy for cholesky are different. The numpy version returns  a lower triangular matrix, and the scipy version returns an upper triangular matrix. Hence you get different behavior depending on whether you have scipy installed or not.</p>
<p dir="auto">Below is a script that duplicates this behavior (without forcing you to uninstall scipy to test).</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="import numpy as np
import numpy.linalg as la
import numpy.dual as dual


P = np.cov(np.diag([1., 2., 3.]))
c1 = la.cholesky(P)
c2 = dual.cholesky(P)
assert c1[1,2] == c2[2,1]
assert c1[1,2] != c2[1,2]"><pre class="notranslate"><code class="notranslate">import numpy as np
import numpy.linalg as la
import numpy.dual as dual


P = np.cov(np.diag([1., 2., 3.]))
c1 = la.cholesky(P)
c2 = dual.cholesky(P)
assert c1[1,2] == c2[2,1]
assert c1[1,2] != c2[1,2]
</code></pre></div>
<p dir="auto">Suggested fix: I dunno. Some choices that come to mind</p>
<ul dir="auto">
<li>Add a <em>lower</em> parameter to numpy, defaulted to true, and add a non-optional parameter <em>lower</em> to dual.cholesky. This will break all code using dual.cholesky, but I am not a fan of silent failures.</li>
<li>Remove cholesky from dual</li>
<li>scipy's cholesky has an optional <em>lower</em> param that can be set to true. If dual.py could be modified to set that to be true than numpy.linalg.cholesky and dual.cholesky will behave the same, which is presumably the behavior that the programmer wants. I say 'presumably' because the programmer may be used to using the scipy version and expecting the upper-triangular behavior; they will be surprised by this choice.</li>
<li>Add a warning in the documentation that the behavior is inconsistent. I dislike this because I found out about this problem the hard way - my output 'looked' wrong. Sure, documentation would have helped me find it faster, but either consistent behavior or an exception would have been preferred by me.</li>
<li>Make cholesky in both scipy and numpy return upper-triangular. This is a terrible option IMO because it would break so much code.</li>
</ul>
<p dir="auto">The top two are the most "painful" to the users of the library, but they have the advantage of forcing them to think about and deal with the problem. The others allow silent failures.</p>