<div dir="ltr"><div><div><div><div><div>Thanks for all you answers.<br><br></div>The problem might be that I am using some resampled data extracted on cortical surface as well as coordinates in subcortical ROIs, so this is similar to grayordinates in HCP but it is not HCP data, so I have not really a way to go back to voxel space.<br></div>Resampling occurs anyway during preprocessing so I thought it would be ok.<br><br></div>I have not per say correlated the number of neighbors within radius with searchlight results but just displaying it makes me have concerns about potential bias as I know classifiers are sensitive to feature space dimension.<br></div>The distribution of feature number is really widespread due to the surface constraint, for example a 6mm radius have nfeat from 6 to 118 which definitely have an influence on classification.<br></div><div>Will try to find solution to that.<br></div><div><br></div><div>cheers<br><br></div><div>basile<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 10:55 AM, Christopher J Markiewicz <span dir="ltr"><<a href="mailto:effigies@bu.edu" target="_blank">effigies@bu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/15/2015 09:25 AM, basile pinsard wrote:<br>
> Hi MVPA experts,<br>
><br>
> I have a theoretical question that arised from recent analysis using<br>
> searchlight (either surface or voxel based):<br>
><br>
> What is the most sensible feature selection strategy between:<br>
> - a radius with variable number of features included, which will make<br>
> the different classifiers trained on different amount of dimensions;<br>
> - a fixed number of closest voxels/surface_nodes that would represent<br>
> different surface/volume/spatial_extent depending on the localization.<br>
<br>
</span>From my reading, the more common is the former. This is probably<br>
because, without evidence that your results particularly correlate with<br>
searchlight size, the more interpretable figure is one in which each<br>
voxel represents a statistic taken over a fixed spatial extent.<br>
<br>
A fixed number of voxels (I agree with Jo that one should always use<br>
voxels; even if you are using surface nodes to define a neighborhood,<br>
these should be mapped back to voxels to avoid smoothing and resampling)<br>
is beneficial if you are using an error metric that is sensitive to<br>
dimensionality, such as mean squared error.<br>
<br>
With a surface searchlight of radius 9mm, I get a distribution of<br>
searchlight sizes (in one subject) that's approximately normal(66, 8). I<br>
have not found that the cross-validation training error of classifiers<br>
(linear SVM, mostly) is particularly sensitive to searchlight size. On<br>
the other hand, attempting to use the same searchlights with regression<br>
problems produces results that correlate strongly (positively or<br>
negatively, depending on regression algorithm) with number of voxels.<br>
<span class=""><br>
> I had the examples with surfaces, for which I used a spherical templates<br>
> (similar to 32k surfaces in HCP dataset) transformed into subject space.<br>
> I computed the number of neighbors for each node with a fixed radius and<br>
> noted a differential sampling resolution in the brain, which somewhat<br>
> overlay with my network of interest (motor) and thus my concerns.<br>
<br>
</span>Do your preliminary results correlate with searchlight size across<br>
several regions? That would be my primary indication that this is a concern.<br>
<span class=""><br>
> With voxel based searchlight, depending on masking voxels on the borders<br>
> of the mask will have less neighbors in a fixed radius sphere.<br>
<br>
</span>Could you smear the mask with your searchlight, i.e. extend it in all<br>
directions? You'll still be including (presumably) uninformative voxels,<br>
but at least you won't be dimensionality itself that gets you.<br>
<span class=""><br>
> PyMVPA has only this strategy for now, but I read many papers with fixed<br>
> amount of features in Searchlight.<br>
><br>
> What do you think?<br>
><br>
> I did an ugly modification to have a temporary fixed feature number<br>
> (closest) on surface but it should be optimized:<br>
> <a href="https://github.com/bpinsard/PyMVPA/commit/1af58ea8a57882ed57059491c19d83bed43e0bce" target="_blank">https://github.com/bpinsard/PyMVPA/commit/1af58ea8a57882ed57059491c19d83bed43e0bce</a><br>
<br>
</span>If I'm reading this right (I haven't dug into the PyMVPA surface<br>
searchlight implementation), this is selecting a maximum number of<br>
surface nodes, and then mapping that to voxels, and will still end up<br>
with variable numbers of voxels, depending on the density of surface nodes.<br>
<br>
What about sorting nodes based on distance, mapping to voxels, and then<br>
taking the first max_features voxels?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Christopher J Markiewicz<br>
Ph.D. Candidate, Quantitative Neuroscience Laboratory<br>
Boston University<br>
<br>
</font></span><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/cgi-bin/mailman/listinfo/pkg-exppsy-pymvpa" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exppsy-pymvpa</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><font size="1">Basile Pinsard<br></font></div><i><font size="1">PhD candidate, <br></font></i></div><font size="1">Laboratoire d'Imagerie Biomédicale, UMR S 1146 / UMR 7371, Sorbonne Universités, UPMC, INSERM, CNRS</font><br><font size="1"><span><span style="color:#333333"><span style="font-family:Arial,serif"><span lang="en-GB"><em>Brain-Cognition-Behaviour Doctoral School </em></span></span></span><span style="color:#333333"><span style="font-family:Arial,serif"><span lang="en-GB"><strong>, </strong>ED3C<strong>, </strong>UPMC, Sorbonne Universités<br>Biomedical Sciences Doctoral School, Faculty of Medicine, Université de Montréal <br></span></span></span></span></font><font size="1">CRIUGM, Université de Montréal</font><br></div></div></div></div>
</div>