<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hmmm…. I should know better than to talk off the top of my head like that…</div><div><br></div><div>Well, part right, part wrong.</div><div><br></div><div>It's easy enough to just try it out and see what Matlab says the rank is of the data. I took some Cz-referenced 129-channel data and then rereferenced it to mean mastoid and to average reference.</div><div><br></div><div><div>>> rank(undata)</div><div><br></div><div>ans =</div><div><br></div><div> 128</div></div><div><br></div><div>>> rank(mmdata)</div><div><br></div><div>ans =</div><div><br></div><div> 128</div><div><br></div><div>>> rank(ardata)</div><div><br></div><div>ans =</div><div><br></div><div> 128</div><div><br></div><div>so the bottom line is that average reference doesn't reduce the rank but neither does mean mastoid (my error).</div><div><br></div><div>As for the wiki page you linked to, it's worded in a confusing way. It's not that "the average reference reduces the rank of the data" necessarily. What it should say is that it doesn't increase the rank of the data. So if you start off with 128 recording channels and a reference channel (n=129) and rank is 128 (because voltage data is relative by definition so two channels only give you one waveform), then after average reference, the rank is still 128 even though it now looks as though you've got 129 channels with independent waveforms. If you dropped the 129th reference channel and then computed an average reference channel, you would indeed lose another rank (as seen below) but that would be because you were doing the procedure incorrectly and had deleted a channel of meaningful information (even though it is flat). The flat reference channel should always be included in the average reference computation. The same goes for computing the mean mastoid reference (or any other rereference), although unfortunately a lot of systems throw that information away.</div><div><br></div><div><br></div><div>>> rank(ar128data)</div><div><br></div><div>ans =</div><div><br></div><div> 127</div><div><br></div><div>I definitely need to look into the effects of bridging more closely, especially for frequency-based applications. This has been a very helpful discussion!</div><div><br></div><div>Joe</div><div><br></div><div><br></div><div><br></div><div><div>On Jan 23, 2013, at 6:44 AM, Matt Craddock <<a href="mailto:matt.craddock@uni-leipzig.de">matt.craddock@uni-leipzig.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 18/01/2013 20:39, Joseph Dien wrote:<br><blockquote type="cite">Another thought occurs to me. I have indeed noticed a tendency for<br>increased noise to show up in my own ICA-based artifact correction<br>routine in the EP Toolkit (Tim Curran first reported it to me). I've<br> never worked out why. I ended up implementing a trial-by-trial<br>workaround wherein the eyeblink factors are removed from a given<br>trial only when it reduces the overall variance of the trial. In<br>other words, when the benefit outweighs the cost. The increased<br>noise that I see is small enough that it gets averaged out for ERPs<br>so has not been an issue. Could be an issue for frequency-based<br>measures though. I need to look into this further. Anyway, what<br>you're reporting seems more severe than anything I've observed so<br>perhaps something different.<br></blockquote><br>Hi Joe, Kristina, and all,<br><br>I'm mostly dealing with frequency analysis; the noise does indeed pose<br>some problems for frequency-based measures, since it translates into<br>noise in the gamma band range (>40Hz, mostly). This issue has been<br>reported previously on this list:<br><br><a href="http://sccn.ucsd.edu/pipermail/eeglablist/2011/004316.html">http://sccn.ucsd.edu/pipermail/eeglablist/2011/004316.html</a><br><br>and the conclusion then was that it was down to reduced rank:<br><br>http://sccn.ucsd.edu/pipermail/eeglablist/2011/004319.html<br><br>Hence why I jumped on that as an explanation when I saw Kristina's<br>original post. My situation turns out to be a little different from<br>hers, in that I use average reference rather than linked mastoids, and<br>don't keep a reference channel in the data, so it didn't seem to be caused by the duplicate data issue Makoto identified (although sometimes it may have been - see later; but wouldn't that also be a rank reduction?). In my case I've found doing PCA first (reducing number of components to the rank, so usually only to numChannels-1) makes this problem go away, but given that everybody said avoid doing that first, I also had a closer look at the datasets where I'd had this problem and found in some cases that there were *very* high correlations between some channels (.99 in one case!). Removing one of those channels before running ICA (and *not* doing PCA) also fixed the problem. I didn't see any major differences in the components between PCAing first and removing the channels, though of course that's not to say there aren't any that would emerge if looking at them more systematically!<br><br><blockquote type="cite">Average reference doesn't reduce the rank. Basically all it does is<br>to virtually move the reference site. In the original<br>vertex-referenced data, there is informational ambiguity as to<br>whether recorded voltage fluctuations are due to activity at the<br>reference site or at the recording site (unavoidable since voltages<br>are by their nature relative and so require a reference site). When<br>one algebraically rereferences the data to a different single<br>reference site (including the virtual reference site of average<br>reference) there is no increase in informational ambiguity. Mean<br>mastoid reference does increase increase informational ambiguity<br>because it introduces a new ambiguity of whether reference site<br>activity is occurring at the left or right mastoid. In essence, this<br>is because a subset of the total set of electrodes has been singled<br>out and mixed together. This increased ambiguity reduces the rank by<br>one.<br></blockquote><br>Hmm, but this page says that average reference does reduce rank, and that's been what people have said on this list for quite a while.<br>http://sccn.ucsd.edu/wiki/Linear_Representations_and_Basis_Vectors<br><br>Happy to be corrected, but on the whole I'm left a little puzzled - the default behaviour of EEGlab's GUI is to suggest PCA reduction if your data is reduced rank. Given the consensus seems to be to avoid PCA, does that need to change, or at least to suggest people be very cautious about using it and try to find alternative ways of conditioning their data, be that removing channels or whatever?<br><br>Cheers,<br>Matt<br><br>-- <br>Dr. Matt Craddock<br><br>Post-doctoral researcher,<br>Institute of Psychology,<br>University of Leipzig,<br>Seeburgstr. 14-20,<br>04103 Leipzig, Germany<br>Phone: +49 341 973 95 44<br></blockquote></div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Courier; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; font-size: 12px; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><br>--------------------------------------------------------------------------------</div><div><br></div><div>Joseph Dien,</div><div>Senior Research Scientist</div><div>University of Maryland </div><div><br></div><div>E-mail: <a href="mailto:jdien07@mac.com">jdien07@mac.com</a></div><div>Phone: 301-226-8848</div><div>Fax: 301-226-8811</div><div><a href="http://joedien.com//">http://joedien.com//</a></div></div><br></div><div><br></div><div><br></div><br></div></span></div></span></div></span></div></span></div></span></div></span></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br></body></html>