[pymvpa] searchlight concept and pyMVPA

[Vadim Axel]

Thanks, Michael.
Let's see if I understand correctly what you mean by "extracts boxcar-shaped
volume". Consider a simplest case that in my fast ER design the trail length
is one TR. You return a vector of single datapoints for each of the
condition trials. But how you take in the account the previous event(s),
which contaminated the mine? Do these values of your returned data points
differ from the original values, which I used as an input or you just
arrange them according to events?
BTW, do you know how other software (SPM, for example) does this fast ER
extraction? Somehow making design pseudo with optseq helps to extract the
events.

BTW2:  the site search box doesn't trim spaces at the end of the input and
consequently finds nothing.


On Fri, May 15, 2009 at 12:39 PM, Michael Hanke <michael.hanke at gmail.com>wrote:

> Hi Vadim,
>
> On Fri, May 15, 2009 at 12:19:45PM +0200, Vadim Axel wrote:
> > Hi,
> >
> > I feel a little bit confused with all these studies which use searchlight
> > analysis concept, but practically make it in completely different way.
> > Specifically:
> >
> > 1. Kriegeskorte et al 2006 (and Kriegeskorte et al 2007) neither talked
> > about classification, nor SVM. His proposal was to take the output
> (contrast
> > image between two conditions of a standard GLM for unsmoothed data), to
> > define a sphere, make some smart average in this sphere and then iterate
> > over all possible spheres in order to find which spheres pass the
> threshold
> > (aka significant regions). No classification, no raw data.
> >
> > 2. Haynes et al 2007 or Soon et al. 2008 ("mind reading"), extends
> > Kriegeskorte by taking beta vectors per condition / session and by using
> SVM
> > for a iterating sphere finds regions, which result in best
> classification.
> > No raw data and classification is based on some 10 data points per
> > condition. The similar methodology I think was used here as well:
> Hassabis
> > et al. 2009
> >
> > 3. Some new stuff of Li at al. 2009 (
> > http://www.cell.com/neuron/abstract/S0896-6273(09)00239-6<http://www.cell.com/neuron/abstract/S0896-6273%2809%2900239-6>
> <http://www.cell.com/neuron/abstract/S0896-6273%2809%2900239-6>)
> >
> > They used Kriegeskorte searchlight method (and code as well) but then
> they
> > employed SVM to classify searchlight regions on averaged two volumes data
> > points. Given that their design was fast ER I am not fully understand how
> > this classification worked "out of the box" (I haven't succeed to dig any
> > details from the paper).
> >
> > The Questions:
> > As far as I understand, pyMVPA searchlight doesn't run univariate GLM,
> but
> > just runs classification for sphere in different locations?
> > An assumption, that I have to feed it with block design data. unless I am
> > using ERNiftiDataset, which is under development?
>
> Searchlight in PyMVPA is simply an abstraction of the idea of computing
> _something_ in any sphere of a given size in the dataset. To that end it
> doesn't matter what you want to compute. It could be a a simple GLM on
> the mean signal, a SVM classification accuracy, or something totally
> different -- any (in PyMVPA terminology) DatasetMeasure() should work.
>
> > I would appreciate if you can send any paper reference on how
> ERNiftiDataset
> > extracts events from fast ER design.
>
> Hmm, paper .... there is none (yet). Currently, the best would probably
> be to take a look at the searchlight examples in the docs:
>
>  http://www.pymvpa.org/examples/searchlight_minimal.html
>  http://www.pymvpa.org/examples/searchlight_2d.html
>  http://www.pymvpa.org/examples/searchlight_dsm.html
>
> ERNiftiDataset simply extracts boxcar-shaped volume series from a 4d
> timeseries, defined by onset and duration of events. What you do with
> those boxcars is up to you. You could time-average them, or do more (or
> even less) fancy things, before feeding them into a classifier.
>
> We are thinking about writing a manuscript that shows how to do that
> with a really fastER design -- but that is work in progress and doesn't
> even have the highest priority ATM.
>
> HTH,
>
> Michael
>
>
> --
> GPG key:  1024D/3144BE0F Michael Hanke
> http://apsy.gse.uni-magdeburg.de/hanke
> ICQ: 48230050
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-exppsy-pymvpa/attachments/20090515/9b8cd57b/attachment-0001.htm>