[MRG][DOC] Add GFP to the glossary

[massich]

This PR continues #5796 by adding an entry to the glossary and pointing at it.

@jona-sassenhagen can you (or anybody else) edit the glossary entry with
meaningful info? Thx. I think it would be good also to point to back to whatever
tuto/example explains better GFP.
(maybe examples/time_frequency/plot_time_frequency_global_field_power.py?)

[codecov]

Codecov Report

Merging #5804 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5804      +/-   ##
==========================================
+ Coverage   89.32%   89.33%   +<.01%     
==========================================
  Files         408      408              
  Lines       74303    74303              
  Branches    12293    12293              
==========================================
+ Hits        66374    66376       +2     
+ Misses       5072     5070       -2     
  Partials     2857     2857

[massich]

@drammock can you take over this one? thx

cross refere: #6321

[drammock]

In order to be write an honest glossary entry for GFP, we would need to do it the same way everywhere. Sadly that is not happening:

• evoked.data.std(axis=0) is used:
  • mne.viz.utils._find_peaks
  • tutorials/evoked/plot_object_evoked.py
• sqrt(mean(evoked.data ** 2, axis=0)) is used:
  • mne.viz.evoked._plot_lines
• mne.baseline.rescale(sum(evoked.data ** 2, axis=0)) is used:
  • examples/time_frequency/plot_time_frequency_global_field_power.py

(The first two methods are equivalent, but the last one is not)

[drammock]

rendered glossary

[larsoner]

Perhaps some of the confusion arises because for EEG data with a common average reference the RMS power at each time point across sensors is the same as the standard deviation (but without CAR it's not due to the mean subtraction step). I'm actually not sure which we should use everywhere, probably the std. But in any case, this looks good, thanks @drammock !

[drammock]

@larsoner it strikes me as low priority, but to improve consistency (and ensure future additions remain consistent) WDYT about adding a GFP function that triages based on instance type (and maybe incorporates some of the baselining functionality that @dengemann is using in that time-freq-GFP example?)

[larsoner]

Sure, a private function would be nice. It might not even need to triage based on type, it's entirely possible the sum should be mean in the TF code. But someone would need to check (and also check that you should subtract the mean at each time point, maybe you don't and just rely on the baselining or high-passing instead...)