[Eeglablist] ICA and single vs. double precision data

Arnaud Delorme arno at salk.edu
Mon Nov 5 14:02:32 PST 2007


[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



More information about the eeglablist mailing list