ENH: reorder rows, prioritize by top-2 max difference

[bcipolli]

This addresses two things:

1. The component matching was tweaked such that rows with the clearest preference for a column gets to match first (take two lowest distance scores, subtract & normalize, allow largest value to select first).
2. Rows get reordered according to the same score.
3. Normalize by subtracting off the lowest similarity score... no division.

@atsuch It's looking reasonable:

[bcipolli]

@atsuch Looks like this is doing much better matching. The sorting doesn't do too much for me, but the better matching makes the results much more interesting!

I'm seeing two things in both vs. rl:

• In general, RL is cleaner / better contrast than both. Perhaps it has to do with using 40 components (20+20) vs. 20?
• both gets a lateralized finger movement component (left); RL actually finds left and right finger components (probably from different tasks), and associates them.
• RL is getting asymmetry in pain that's not apparent in the both data:

Some things to do:

• Looks like we should allow re-using matches. For example, both has left and right finger movements as separate components. We get the RL components and match them, but then can only match up with one of the two both components.
• Restricting usage of one component also affects lateralized functions like language. Nothing matces, so it grabs some randomly "similar" component.
• The language issue also affects similarity score. Since that RL match is not compelling, it's going to decrease the similarity score to the language component in both. So perhaps computing similarity between RL and both by: matching R to both:R, L to both:L, and allowing reuse of matches (and then visualizing any components never chosen as the best match).

[atsuch]

The matching and reordering look fantastic!

As for allowing to reuse matches, I thought about it too, just hadn't got around to discuss it with you. Whether we do comparisons your way (RL to both) or my way (R- or L- only to both), I wasn't sure if we should be forcing one-to-one matching for all the components. We are hypothesizing that some wb components will have good match than others, depending on how much the interhemispheric interactions are affecting the wb component. That's why I wanted to be able to compare match scores not just by rows but across the whole matrix.

Need to go now but will comment more...!

[bcipolli]

Thanks @atsuch ! Feel free to open github issues for individual things to discuss and propose. It's a common way to make conversations focused on code changes, and to make discussions easy to find.

Sounds like this code is the right kind of thing, so I will merge it!