[Eeglablist] Problems with rank computation - ICA

Tue Feb 28 12:08:55 PST 2012

Problems with rank():  To the best of my recollection, a distinct bug
appeared in some Matlab versions of their rank() function (including the
version we were using) -- we had to insert a workaround (using lower-level
Matlab math functions) to avoid nonsensical consequences ...  If infomax
ICA (runica/binica) is set to work using a rank higher than the true rank
of the data, then the weights will continue to increase and will then 'blow
up' ... But reducing the number of components computed below the actual
rank will have negative consequences in most cases.

Scott Makeig

On Mon, Feb 27, 2012 at 6:26 AM, Matthew Stief <ms2272 at cornell.edu> wrote:

> Hey Tarik,
>
> You say that it will look ok, but nevertheless a rank has been lost from
> re-referencing to the average so ICAs run in this way are being overfitted,
> and are thus suboptimal, are they not?  I've run through most of my data
> with the rank calculated incorrectly and mostly it looks "normal" but I am
> going back through it to make sure that everything is correct and I want to
> make sure I am doing things optimally because some of my results are null
> and I want to be very sure of them before I publish.
>
> Just to confirm, if pop_runica did in fact opt for the lower of the two
> candidate ranks represented in that error message, that is if it chose to
> use the results of this code:
>
> covarianceMatrix = cov(tmpdata', 1);
> [E, D] = eig (covarianceMatrix);
> rankTolerance = 1e-7;
> tmprank2=sum (diag (D) > rankTolerance);
>
> instead of opting for the result of this code:
>
> tmprank = rank(tmpdata);
>
> Then because the correct rank is less than the number of channels it would
> necessarily have to run PCA to not run an ICA with too many ranks?  And
> this would be exactly identical to overriding the rank calculation by
> specifying a PCA with a particular number of ranks?  This is what I
> understand is the case but I can barely understand this stuff so I just
> want to make absolutely sure.  I understand if there's no definitive
> solution at this point, but I would be very grateful if anyone had the time
> to help me understand exactly what the problem is.
>
> What I've done in my data processing code is this...
>
> correctRank = EEG.nbchan-1;
> EEG = pop_runica(EEG, 'icatype', 'runica', 'pca', correctRank, 'extended',
> 1);
>
> Which seems to work fine.  But I would still love an explanation of why
> pop_runica is calculating rank in this mysterious way.  I mean, what would
> be the dangers of me simply changing this bit of code at the end of
> pop_runica
>
> tmprank2 = max(tmprank, tmprank2);
>
> to this?
>
> tmprank2 = min(tmprank, tmprank2);
>
> Another question about rank calculation in pop_runica.  What exactly is
> this code doing?
>
> tmprank = getrank(tmpdata(:,1:min(3000, size(tmpdata,2))));
>
> For the life of me I can not figure out exactly what the getrank()
> function does.  I can't find it anywhere.  How is it different from the
> normal old rank() function?
>
> And how does the rank calculation code in the main body of pop_runica
> relate to the rank calculation at the end, which is the code that seems
> relevant for the error message that Marco and I keep getting?  How does it
> decide to go from this
>
> tmprank = getrank(tmpdata(:,1:min(3000, size(tmpdata,2))));
>
> to this?
>
> function tmprank2 = getrank(tmpdata);
>     tmprank = rank(tmpdata);
>     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>     %Here: alternate computation of the rank by Sven Hoffman
>     %tmprank = rank(tmpdata(:,1:min(3000, size(tmpdata,2)))); old code
>     covarianceMatrix = cov(tmpdata', 1);
>     [E, D] = eig (covarianceMatrix);
>     rankTolerance = 1e-7;
>     tmprank2=sum (diag (D) > rankTolerance);
>     if tmprank ~= tmprank2
>         fprintf('Warning: fixing rank computation inconsistency (%d vs %d)
> most likely because running under Linux 64-bit Matlab', tmprank, tmprank2);
>         tmprank2 = max(tmprank, tmprank2);
>     end;
>
> Thanks for everyone's help as always.
>
> -Matthew Stief
>
>
>
>
> On Sun, Feb 19, 2012 at 2:24 PM, Tarik S Bel-Bahar <
> tarikbelbahar at gmail.com> wrote:
>
>> If using normal runica, you could pca reduce by one dimension, to reflect
>> the reduction by one rank, because of average referencing. Amica from jason
>> palmer should avoid these issues. Overall, your decomposition should look
>> okay and interpretable, even if you are getting those messages, especially
>> if you have followed all other preprocessing steps such as filtering,
>> removing baseline, and artifactual period removal. There was some
>> discussion about rank dimensions in data on previous eeglab discussions,
>> which you can search for, including a note about that warning message that
>> you are getting, but I dont think a final principled solution was setup.
>>  On Feb 19, 2012 10:22 AM, "Marco Montalto" <montaltomarco at onvol.net>
>> wrote:
>>
>>> Dear all,
>>>
>>> I have data from 13 subjects which I am filtering, removing bad
>>> channels, re-referencing to average, epoching and then selecting epochs.
>>> When I run ICA I get the following warning (example from one particular
>>> dataset):
>>>
>>> Warning: fixing rank computation inconsistency (31 vs 30) most likely
>>> because running under Linux 64-bit Matlab
>>>
>>> And I get as many IC components as there are remaining channels.
>>>
>>> But for some datasets, which have been processed similarly to the other
>>> datasets, ICA correctly gives one component less than there are remaining
>>> channels.
>>>
>>> I have switched from single precision to double precision and now all
>>> datasets, after running ICA, give equal number of components as there are
>>> remaining channels (but still giving the warning message above).
>>>
>>> I am using EEGLAB version 10.2.5.8b running on MATLAB version 7.12.0.635
>>> (R2011a) on a Macbook Pro (Dual Core).
>>>
>>> Can anyone give me some advise regarding this warning? Should I ignore
>>> it and continue working with double precision or am I doing something wrong?
>>>
>>> Thanks!
>>>
>>> Marco
>>>
>>
> --
> _________________________________________________________________
> Matthew Stief
> Human Development | Sex & Gender Lab | Cornell University
> http://www.human.cornell.edu/HD/sexgender
>
>
> Heterosexuality isn't normal, it's just common.
> -Dorothy Parker
>
> _______________________________________________
> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
> To unsubscribe, send an empty email to
> eeglablist-unsubscribe at sccn.ucsd.edu
> For digest mode, send an email with the subject "set digest mime" to
> eeglablist-request at sccn.ucsd.edu
>

-- 
Scott Makeig, Research Scientist and Director, Swartz Center for
Computational Neuroscience, Institute for Neural Computation; Prof. of
Neurosciences (Adj.), University of California San Diego, La Jolla CA
92093-0559, http://sccn.ucsd.edu/~scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20120228/e6cfff72/attachment.html>