The problem extends to input vector that are almost constant, due to finite arithmetic issues in the division by zero. The script

import numpy as np
from scipy.spatial.distance import correlation

X1 = np.array([1, 1, 1])
noise = np.array([.5, 0, -.01])
X2 = np.array([2, 4, 6])
for eps in np.linspace(-1e-15, .0, 50):
    print(correlation(X1 + eps * noise, X2))

outputs (on master branch)

0.166666666667
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.147197134578
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.133974596216
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
0.292893218813
RuntimeWarning: invalid value encountered in double_scalars
  dist = 1.0 - np.dot(um, vm) / (norm(um) * norm(vm))
nan
nan
nan
nan
nan
nan

It's not clear to me that "BUG: handle corner case" really applies here. The correct limit of the output as the input approaches the corner depends on the direction from which it is approaching, right? I think this is a classic reason to use NaN, analogous to the reasoning behind NaN for x/y as x->0 and y->0.

I think this is a classic reason to use NaN, analogous to the reasoning behind NaN for x/y as x->0 and y->0.

I agree. Although, I think that most if not all use cases of correlation have to check whether a nan is returned and if that nan was returned because one of the vector was (nearly) constant, and not for other reasons --for example if a nan was already present in the input vectors. Constant inputs can happen with real data and therefore handling that corner case is necessary for robustness. That's the kind of wrapper I am thinking to implement to fix those issues in sklearn.

In case we do not find this "bug fix" appropriate on the scipy side, I would like correlation's docstring to be more explicit about the nan outputs. I can change the PR in this sense if you guys agree.

You're going to have to further convince me that it's correct to return 0 rather than NaN in these cases. Mathematically, the stated formula gives 0/0 -> NaN. Conceptually, the correlation distance is a measure of the linear relationship between two variables, and my intuition is that if there is no baseline to measure against then the question of linear relationship is meaningless, and NaN is as good a "missing data" marker as we have.

OK, there are two apparent -1s, and no action from OP for a week. FTR and FWIW, I agree with Jake and Alex above. The stats.stackexchange link quoted as a justification has a bit more discussion and I fail to read it as a full justification of the suggestion here. IMO, a reference to well-reputed literature could sway it. Otherwise, I'd recommend rejecting and closing this PR.

Note, if this were in stats, I would have recommended "don't fix", similar to the discussion for the t-test (where I was on the no nan side and got convinced otherwise).

In spatial it could be a bit more pragmatic, IMO, but I don't see a convincing argument for any specific value as alternative to nan.

I have stopped working on this, waiting for more opinions, and decide to "fix" those issues on the scikit-learn side meanwhile.

I am good with your decision, if you want to close the PR. I suggest that those limit behaviours get documented in the docstrings though.

If you agree to touch the documentation of the distance functions, I can work on that.

I think clarifying the documentation would be great @giorgiop. Either as a replacement of this PR (then please also change the title), or close this PR and send another one for the documentation, whichever you prefer. Thanks!

Ok, the agreement back in October seemed to be that we'd rather keep the current behavior, and there is no activity since then. I'm then closing this as a wontfix. If at some point in time we want to reconsider, the patch is still available. Thank you @giorgiop, thanks to reviewers.