Thanks for the prompt response. I guess a hidden message was &quot;Don&#39;t use the 0.4.5 version. If you want to do searchlight on ER data, download the 0.6 version &quot; :) Am I right?   Will 0.5  also do a trick?<br><br>
<div class="gmail_quote">On Wed, Dec 29, 2010 at 1:58 PM, Yaroslav Halchenko <span dir="ltr">&lt;<a href="mailto:debian@onerussian.com">debian@onerussian.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Anna,<br>
<br>
Sorry for the delay with replies.<br>
<br>
The main issue is that 0.4 is not ready to provide adequate<br>
support for doing spatio-temporal searchlight analysis &quot;properly&quot; out of<br>
the box.  That was one of the reason for initiating development of<br>
0.5.<br>
<br>
What I meant by &quot;properly&quot;:<br>
<br>
  you are specifying &quot;radius&quot; for your searchlight (e.g. 1), is<br>
  that in voxels?  seconds? mm?<br>
<br>
  could we add distances in time and space together?<br>
<br>
so we wanted to have a clean way to specify radii per each dimension (i.e.<br>
space/time) without hassle, so that they (time and space) do not<br>
&quot;interfere&quot; with each other.<br>
<br>
in 0.4 you could probably craft some custom metric and distance function<br>
which would have proper separation between the two &quot;dimension&quot;<br>
(time/space), but we do not have it built-in.<br>
<br>
What you probably could do (but once again -- we haven&#39;t tested that<br>
much in 0.4) -- assign a metric where you disregard difference between<br>
time and space and just ask for neighboring voxels in space and time,<br>
but once again, it would make voxel  (1,1,1) at time 0 as distant from<br>
(0,0,0) at time 0, as (1,1,0) at time 1, and depending on the radii<br>
might not take any other voxel at time 1; so it litterally becomes some<br>
kind of spatio-temporal ellipsoid ;)<br>
<br>
to accomplish that you just assign the metric to both chainmapper of the<br>
ds and its trailing mapper (which has a metric with correct dimensions<br>
actually, but adding actual mm^2 to sec^2 has even less sense ;)):<br>
<br>
ds.mapper._mappers[1].metric = \<br>
ds.mapper.metric = DescreteMetric(elementsize=[1.0, 1.0, 1.0, 1.0],<br>
                                  distance_function=cartesianDistance)<br>
<br>
That might work (at least it doesn&#39;t crash ;))<br>
<br>
But, once again, even if it works, its interpretation and validity are at<br>
question ;)<br>
<br>
For doing &quot;correct&quot; Spatio-temporal searchlight in upcoming 0.6, see<br>
<a href="http://dev.pymvpa.org/tutorial_eventrelated.html#if-that-was-easy" target="_blank">http://dev.pymvpa.org/tutorial_eventrelated.html#if-that-was-easy</a> where search<br>
&quot;radii&quot; can be specified directly per each dimension (space/time).<br>
<div class="im"><br>
On Wed, 29 Dec 2010, Anna Manelis wrote:<br>
<br>
&gt;    I am trying to use searchlight on event-related fMRI data. The error<br>
&gt;    message suggests that there is a problem with assigning metrics to<br>
&gt;    MappedDataset.<br>
</div>--<br>
=------------------------------------------------------------------=<br>
Keep in touch                                     <a href="http://www.onerussian.com" target="_blank">www.onerussian.com</a><br>
Yaroslav Halchenko                 <a href="http://www.ohloh.net/accounts/yarikoptic" target="_blank">www.ohloh.net/accounts/yarikoptic</a><br>
<br>
_______________________________________________<br>
Pkg-ExpPsy-PyMVPA mailing list<br>
<a href="mailto:Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org">Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa</a><br>
</blockquote></div><br>