MRG, ENH: Add tol_kind option

[larsoner]

Digging through our code, I was a bit surprised to see that the tol we apply in compute_rank is an absolute one on the singular values (computed after whatever normalization/scaling you have selected). I've added a tol_kind option that allows treating this as a relative tolerance.

Another option would be to leave tol and add rtol, but that's weird because tol='auto' (and tol='float32') already only behave as a relative tolerance, because they do the same thing that pinv does (scale relative to the max singular val).

Testing with some local MaxFiltered data suggests that it's more robust and flexible than using an absolute tol. I also was able to add it to the dense test_rank.py tests without too many modifications/attempts to find a good value, which I can't say about the absolute version.

[codecov]

Codecov Report

Merging #7736 into master will decrease coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #7736      +/-   ##
==========================================
- Coverage   90.23%   90.17%   -0.07%     
==========================================
  Files         455      455              
  Lines       84698    84660      -38     
  Branches    13421    13419       -2     
==========================================
- Hits        76429    76341      -88     
- Misses       5402     5444      +42     
- Partials     2867     2875       +8     

[agramfort]

this works but I would keep in mind that relative will not work always and will typically break if you have a strong artifact that boosts the first eigenvalue (I've see this before)

[larsoner]

Indeed it can break in that case. My use case is always computing covariances on preprocessed data with such artifactual segments removed via SSP or annotations, so less of an issue there.

[larsoner]

but I would keep in mind that relative will not work always

Also it's important to note that our default is 'auto', and in this mode it's always relative. So our default is to use a relative computation. We're in a weird situation here where 'auto' was relative but any float was not. Arguably we should maybe make tol_kind='relative' by default, but it seems nicer from a backward compat standpoint not to force that on people, since they might have computations that depend on it. And it's not worth a deprecation cycle to change it I don't think.

The bottom line is that people might need to try different things to get the right rank computed for their data depending on what processing they've done (ICA, SSS, etc.) and this just gives you more flexibility, and more consistent ways of doing so.

[larsoner]

(pushed a commit to add a caveat about the single-large-component problem and rebased since there was a seemingly random failure)

[agramfort]

thx @larsoner