[pymvpa] ERNiftiDataset with different event durations

[Matthias Ekman]

Thank you very much for your comments on this.

Yaroslav Halchenko wrote:
> in your case -- do you have a balance in how many delays of different
> length (1,2,3) you use across conditions A and B?
Yes, it is balanced and also the order is counterbalanced, so this 
should be not a problem.
>
> If you have the balanced (ie the same number of trials with 1, 2, 3
> delays for both A and B), then, I think, classifier would actually try to
> classify on the differences among conditions A and B, since it would not
> be able to give preference to any of the conditions based on the delay.
> And you should be safe to take those 4-8 seconds after onset to
> accomodate for sluggish HRF response.
>   
OK, but my feeling was, that the classifier has more problems to focus 
on the differences between conditions A and B if other (irrelevant) 
features are included in the pattern vector. To test this, I performed 
the analysis only with examples covering the 6sec. Delay, so the 
Boxcarmapper included only relevant examples of class A and B. Than I 
changed the event duration just for one second with

     for ev in evs:
        ev['duration'] = 7

and the accuracy substantially decreased (may be this effect could be 
"undone" with correlation stability analysis before classification).
> But why variable delay was chosen? ;)
>   
One of the ideas was to have enough time between CUE and TARGET onset, 
so that they could be modelled with conventional GLM analysis. There was 
also a paper (10.1016/j.cub.2006.11.072) where the authors showed, that 
(due to  sluggish HRF response) decoding becomes better with longer 
delay. One question was if decoding accuracy differs between different 
delay durations in our study... and I didn' thought of a 
temporal-spatial analysis.

Thanks again,
 Matthias
> On Thu, 16 Jul 2009, Matthias Ekman wrote:
>   
>> Lets assume an experimental design looking like this:
>>     
>
>   
>> # Block I
>>     
>
>   
>> CUE_A
>> DELAY_A
>> DELAY_A
>> TGT_X
>> --REST
>>     
>
>   
>> # Block II
>>     
>
>   
>> CUE_B
>> DELAY_B
>> DELAY_B
>> DELAY_B
>> TGT_Y
>> --REST
>>     
>
>   
>> # Block III
>> CUE_B
>> DELAY_B
>> TGT_Y
>> --REST
>> ...
>>     
>
>