Issue 1:
This was the underlying cause of a problem reported on stackoverflow: http://stackoverflow.com/questions/43659827/numpy-error-when-specifying-axis-in-nanmax-while-nansum-works-an-the-same-case

The error is raised when applying nanmax() or nanmin() to an array with object data type and specifying an axis.

Here's the example from my answer:

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)
<ipython-input-5-a020f98a2536> in <module>()
----> 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)
--> 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''

There is no error when the axis is not given:

In [6]: np.nanmax(a)
Out[6]: 4.0

nansum() handles the axis without an error:

In [7]: np.nansum(a, axis=0)
Out[7]: array([4.0, 6.0], dtype=object)

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.

Issue 2:
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.

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.

Below is a script that duplicates this behavior (without forcing you to uninstall scipy to test).

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]

Suggested fix: I dunno. Some choices that come to mind

Add a lower parameter to numpy, defaulted to true, and add a non-optional parameter lower to dual.cholesky. This will break all code using dual.cholesky, but I am not a fan of silent failures.

Remove cholesky from dual

scipy's cholesky has an optional lower 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.

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.

Make cholesky in both scipy and numpy return upper-triangular. This is a terrible option IMO because it would break so much code.

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.