Coverage remained the same when pulling 308c7ef on untom:fix_consensus_score into 3c92686 on scikit-learn:master.

fine, but needs a test

Added a test that shows the issue (fails in the current master, runs through with this patch).

Coverage increased (+0.0%) when pulling 171139f on untom:fix_consensus_score into 3c92686 on scikit-learn:master.

pinging potential reviewers (@arjoly @jnothman ? ). I've been bitten by the bug #2445 again today, I'd like to make sure this patch doesn't fall through the cracks.

This LGTM.

Aside: I am altogether not very happy with the dense data format that the bicluster module currently produces (see #2484). And do you find, @untom, that the consensus_score performs reasonably efficiently? In other work where I have used a similar metric (for coreference resolution which is a special kind of clustering), there is a lot of sparsity in the similarity matrix passed to Kuhn-Munkres (i.e. most pairs of clusters have no overlap in a standard system output), so one gets a substantial speedup by only performing that algorithm on strongly connected components of the similarity graph. Do you think a similar strategy would be beneficial here?

And thanks for the ping!

I absolutely agree with the Issue raised in #2484. I found the picked data format odd as well, back when I started working on PR #2476. As far as performance goes, I've never seen consensus_score come up as bottleneck in my code (I've never worked with large number of biclusters though, usually < 10-20).

Ah of course. Thanks.

pinging @arjoly : could this get a MRG+2 ?

Or maybe @amueller is the right person to ping? (he added the issue to the 0.15.1 milestone)

The fix looks good. Thanks. Sorry the fix was lying around for so long.