[Eeglablist] ICA and single vs. double precision data

Mon Nov 5 23:42:55 PST 2007

Hi Clayton,
You should be very careful when using Matlab with single precision,
especially if you use non-built-in Matlab functions. Some Matlab toolboxes
are not fully compatible with single precision data and, surprisingly, a
non-compatible function will not necessarily display an error or even a
warning if you try to input some data in single precision. For instance, as
it is said in its documentation, the Signal Processing Toolbox (SPT, v. 6.7)
is not compatible with single precision data. However, this compatibility
problem is not mentioned in the help of all functions belonging to that
toolbox and moreover those functions do not always perform any type-check
before performing the computations which means that if for instance you run
in Matlab R2007a (assuming that you have the SPT v. 6.7):

x=double(single(randn(1000,1))); 
h=spectrum.yulear(4); 
figure;psd(h,x); 
figure;psd(h,single(x));

You will observe that if you run the code above several times the behavior
of Matlab is not consistent and, in any case, it's never the expected one.
Sometimes, you might get an error that does not tell you anything about the
data being single, most often Matlab will not display any error or warning
but the 2 figures will be considerably different even though they should be
identical. Said this, I think that runica does not use any non-built-in
Matlab function and therefore you should not have problems using single
precision data. Furthermore, if you have tried runica with a small data
subset and it gives (almost) the same results in single and double precision
you can be quite sure that things are going right. However, single-precision
computation is a rather new Matlab feature and there could be some hidden
bugs related to it.... Moreover, a small bug introducing just small errors
in the computations could have a relatively large impact on stochastic
algorithms like Infomax and make it converge to a sub-optimal solution. So,
summarizing, if I were you I would use single precision only if you do not
have any better choice.

Some alternative solutions that I think you could try:

1) The easiest thing to do is to get more RAM or try some of the solutions
proposed here:  http://www.mathworks.com/support/tech-notes/1100/1107.html. 

2) If the solutions in (1) did not work you can try to modify function
pcsquash.m (where the pre sphering takes place) so that you do not compute
all the eigenvectors/eigenvalues of the data covariance matrix but just some
of the largest ones. This means that you should allow the sphering step to
reduce the dimensionality of your data at least the necessary amount so that
you do not get a out-of-memory error. This can be done by substituting
function eig.m by function eigs.m (see help eigsm) in pcsquash.m.

3) If eigs.m is still too memory demanding you could try some other methods
available in the internet for efficient computation of
eigenvectors/eigenvalues. For instance you can try EIGIFP.m, available here:
http://www.ms.uky.edu/~qye/software.html 

4) If after solving the problem with the eigenvalues/eigenvector computation
you still get memory problems probably the only solution is to considerably
change the implementation of runica or to decrease the data you use for ICA
(e.g. reduce the sampling rate, number of data channels, number of
repetitions, etc).

Hope that helps,
Germán

> -----Original Message-----
> From: eeglablist-bounces at sccn.ucsd.edu [mailto:eeglablist-
> bounces at sccn.ucsd.edu] On Behalf Of Arnaud Delorme
> Sent: Tuesday, November 06, 2007 12:03 AM
> To: c.hickey at psy.vu.nl; eeglablist
> Subject: [Eeglablist] ICA and single vs. double precision data
> 
> [posted on behalf of Clayton Hickey c.hickey at psy.vu.nl]
> Hello EEGLAB-ers,
> 
> I'm currently trying to get ica decompositions for rather large
> datasets, and, no surprise, am running into memory issues. I'm using a
> 64bit windows system with 8 gigs of RAM, Matlab 7.4.0 r2007a, and my
> data is from a 130 channel biosemi system and is composed of around
> 1000
> six second epochs (~1gb per subject). My memory troubles come in the
> sphering of data prior to ICA decomposition.
> 
> One work-around is to run infomax on data represented in single
> precision. I'm doing this by feeding the data directly to runica.m.
> Runica.m does not force conversion to double precision prior to
> beginning decomposition (in contrast to pop_runica.m). The raw
> precision
> of my data is 24 bits. This means that I shouldn't lose any precision
> by
> storing the data in singles. However, I'm a bit nervous feeding singles
> to the ica algorithms because: A.) I'm not familiar enough with the
> algorithms to know if the greater resolution of doubles is required in
> the internal computations, and B.) there is an apparent problem in
> using
> single precision data in matlab 7.x series, as is noted in the code of
> pop_runica.m.
> 
> The decompositions I compute with the single precision data look just
> fine. In comparing components pulled from copies of a data subset, once
> in double and one in single, I can see no dramatic differences (ie.
> small differences that can be accounted for by the fact that ica
> decompositions are never exactly the same twice).
> 
> Any advice or experience with using single precision in ica
> decomposition would be appreciated. More specifically, how much of a
> problem is it to use singles in infomax? Are there still matlab-
> specific
> problems with this? And is binica in fact a better option with single
> data (as is noted in the pop_runica.m code), and if so why is this the
> case?
> 
> If the use of singles results in only a small loss of resolution, I bet
> there are a lot of EEGLAB users who would make this concession in the
> interest of better memory performance...
> 
> Thanks very much,
> 
> Clayton Hickey
> Vrije Universiteit Amsterdam
> _______________________________________________
> eeglablist mailing list eeglablist at sccn.ucsd.edu
> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
> To unsubscribe, send an empty email to eeglablist-
> unsubscribe at sccn.ucsd.edu