E-Prime Data Logging Problem - Reaction Time
1,449 views
Skip to first unread message
Elif yüvrük
Mar 21, 2016, 11:50:56 AM3/21/16
to E-Prime
Hello.
I have some trouble with data logging (reaction time) in E-Prime. My experiment includes two blocks and each block consists of 14 trials, sequentially.
I conducted a pilot study but in the data file I encountered a situation as follows:
Reaction time on the first trial is 68.600 ms, on the second trial it is 66.000 ms, on the third 63.450 ms ... this systematic decreasing pattern goes on like this until the end of the experiment where RT on the last trial is 4550 ms.
Namely, reaction times decrease as number of trials increase and this pattern is visible for all blocks and trials and for all participants without any exceptions.
To note, I used “RT” option in Data Logging section, not the “ RTTime” option.
What might cause this problem? Can someone help me with this?
Thank you so much..
David McFarlane
Mar 24, 2016, 12:07:55 PM3/24/16
to e-p...@googlegroups.com
This problem looked interesting enough that I asked Elif to send me the
program, along with an example .edat2 file that showed the behavior, and
Elif kindly complied. I suspected that the problem might be simple but
subtle, and I did find such a problem.
First some backgroud: Each trial Procedure runs a sequence of a dozen
separate stimulus Slides. Subjects respond by clicking the mouse on the
Slide. Inline code that follows each Slide checks each mouse click --
it ignores mouse clicks until a click occurs in one of the SlideImage
subobjects, after which the program moves on.
In order to allow multiple mouse clicks during the inline response code,
each stimulus Slide has the Mouse input mask set to a Max Count of 100
(in the "Advanced..." dialog). So far, so good. And so that the input
mask will run indefinitely until the inline code finds a response, each
stimulus Slide has Time Limit set to "(infinite)". And therein lies the
problem.
With Time Limit set to "(infinite)", each stimulus Slide keeps silently
taking responses, even after your program has moved on to another
stimulus that uses the same input mask -- i.e., each mouse click acts as
a response not only to the currently displayed stimulus Slide, but also
to all previous stimulus Slides in the Procedure, right up through the
last response to the last stimulus Slide. This behavior may run counter
to your natural expectation, but in fact it is useful behavior once you
understand it, and is exactly how E-Prime should behave.
Now recall that, when you allow multiple responses (Max Count > 1), by
default E-Prime logs only the *last* response for RESP, RT, RTTime, etc.
(to get around this, see the "Multiple Response Collection" example from
the PST website). And as discussed above, with all stimulus Slides set
to a Time Limit of "(infinite)", the last response to the last stimulus
Slide will count as the final response to *all* the stimulus Slides in
the Procedure. So each successive Slide *starts* at a later time, they
all get their final response at the same time, and thus RT values
monotonically decline throughout the Procedure!
So let's follow an example: Your trialprocGor Procedure runs the
stimslideGor1 Slide, and the GetResponseGor1 inline code waits for a
valid mouse response. The Procedure runs on to stimslideGor2 &
GetResponseGor2, but the input mask for stimslideGor1 is still active!
And so on right up through stimslideGor12. The final response to
stimslideGor12 becomes the final response for stimslideGor1 through
stimslideGor12, and the RT value for each stimulus is calculated from
that response. So on one example run, you get RT values of 47791,
40114, ..., 5089.
You would see this more clearly (and would have seen the problem
immediately) if you logged RTTime values in addition to RT values -- you
would then see that you get the same RTTime value for *all* stimulus
Slides in any one run of a trial Procedure. But please do not take my
word for this -- run the exercise for yourself, and then write back to
tell me whether I am right or wrong! I generally favor eliminating
extraneous data columns in order reduce clutter & confusion, but one
must be judicious ("better to have something & not need it than to need
something & not have it"). Whenever you log RT, you should also log
RTTime -- RTTime can serve as a great safety check, as this example shows.
After all that, how to fix this? Three approaches ...
1) Restructure your program. Instead of running a Procedure that runs a
dozen individual stimulus Slides (each followed by an individual
response InLine), use a subtrial List for the stimlulus Slides. The
subtrial Procedure would run one stimulus Slide + response InLine, with
the subtrial List providing information for each of a dozen stimuli.
This restructuring would accomplish several things at once: Data for
each stimlus Slide gets logged right after getting a response, so you
get correct RT values; you reuse one stimulus Slide + response InLine
for all dozen stimuli, instead of needing a dozen objects of each, which
greatly simplifies the program; the response data for each stimulus
Slide in a Procedure will now run down a single column, instead of
across several columns. Personally, I would do this above all else. (I
would also then set Time Limit to "(end of proc)" -- this would not
change any behavior in this case, but it would better represent my
intention.)
2) Once your InLine code sees a valid response, have it explicitly
terminate the input mask: See the InputMaskManager.Terminate topic in
the E-Basic Help. This is the quick & dirty solution to your problem.
If it were me I would do (1), but in the spirit of "belt + suspenders" I
would probably also do this, if I used an input mask at all (see below).
3) Do not use an input mask at all. Instead, use some combination of
Clock.Read, MouseDevice.GetCursorPos, SlideState.HitTest, and
Context.SetAttrib to directly handle the mouse responses (see those
topics in the E-Basic Help facility). This takes considerably more
programming work, but I find it much more adaptable, and I now take this
approach myself (I have written my own extensive routine library for
this purpose, which I might make publicly available some time).
(Technical aside: You could also just disable the logging from stimulus
Slides, and do that (c.SetAttrib) from your InLine response code
immediately after getting a valid response. You see, when you enable
logging from the GUI, E-Prime sets the logged attribute from the value
that it finds at the *end* of the Procedure, which causes your problem.
If you set the attribute right after getting the response, and do
*not* let E-Prime later override that, then all will work as you like.
But if you take this approach then you are asking for trouble when
someone works with the program later -- at least, add extensive comments
in an InLine to explain what you are doing & why!)
---------------
David McFarlane
E-Prime training online:
http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)
program, along with an example .edat2 file that showed the behavior, and
Elif kindly complied. I suspected that the problem might be simple but
subtle, and I did find such a problem.
First some backgroud: Each trial Procedure runs a sequence of a dozen
separate stimulus Slides. Subjects respond by clicking the mouse on the
Slide. Inline code that follows each Slide checks each mouse click --
it ignores mouse clicks until a click occurs in one of the SlideImage
subobjects, after which the program moves on.
In order to allow multiple mouse clicks during the inline response code,
each stimulus Slide has the Mouse input mask set to a Max Count of 100
(in the "Advanced..." dialog). So far, so good. And so that the input
mask will run indefinitely until the inline code finds a response, each
stimulus Slide has Time Limit set to "(infinite)". And therein lies the
problem.
With Time Limit set to "(infinite)", each stimulus Slide keeps silently
taking responses, even after your program has moved on to another
stimulus that uses the same input mask -- i.e., each mouse click acts as
a response not only to the currently displayed stimulus Slide, but also
to all previous stimulus Slides in the Procedure, right up through the
last response to the last stimulus Slide. This behavior may run counter
to your natural expectation, but in fact it is useful behavior once you
understand it, and is exactly how E-Prime should behave.
Now recall that, when you allow multiple responses (Max Count > 1), by
default E-Prime logs only the *last* response for RESP, RT, RTTime, etc.
(to get around this, see the "Multiple Response Collection" example from
the PST website). And as discussed above, with all stimulus Slides set
to a Time Limit of "(infinite)", the last response to the last stimulus
Slide will count as the final response to *all* the stimulus Slides in
the Procedure. So each successive Slide *starts* at a later time, they
all get their final response at the same time, and thus RT values
monotonically decline throughout the Procedure!
So let's follow an example: Your trialprocGor Procedure runs the
stimslideGor1 Slide, and the GetResponseGor1 inline code waits for a
valid mouse response. The Procedure runs on to stimslideGor2 &
GetResponseGor2, but the input mask for stimslideGor1 is still active!
And so on right up through stimslideGor12. The final response to
stimslideGor12 becomes the final response for stimslideGor1 through
stimslideGor12, and the RT value for each stimulus is calculated from
that response. So on one example run, you get RT values of 47791,
40114, ..., 5089.
You would see this more clearly (and would have seen the problem
immediately) if you logged RTTime values in addition to RT values -- you
would then see that you get the same RTTime value for *all* stimulus
Slides in any one run of a trial Procedure. But please do not take my
word for this -- run the exercise for yourself, and then write back to
tell me whether I am right or wrong! I generally favor eliminating
extraneous data columns in order reduce clutter & confusion, but one
must be judicious ("better to have something & not need it than to need
something & not have it"). Whenever you log RT, you should also log
RTTime -- RTTime can serve as a great safety check, as this example shows.
After all that, how to fix this? Three approaches ...
1) Restructure your program. Instead of running a Procedure that runs a
dozen individual stimulus Slides (each followed by an individual
response InLine), use a subtrial List for the stimlulus Slides. The
subtrial Procedure would run one stimulus Slide + response InLine, with
the subtrial List providing information for each of a dozen stimuli.
This restructuring would accomplish several things at once: Data for
each stimlus Slide gets logged right after getting a response, so you
get correct RT values; you reuse one stimulus Slide + response InLine
for all dozen stimuli, instead of needing a dozen objects of each, which
greatly simplifies the program; the response data for each stimulus
Slide in a Procedure will now run down a single column, instead of
across several columns. Personally, I would do this above all else. (I
would also then set Time Limit to "(end of proc)" -- this would not
change any behavior in this case, but it would better represent my
intention.)
2) Once your InLine code sees a valid response, have it explicitly
terminate the input mask: See the InputMaskManager.Terminate topic in
the E-Basic Help. This is the quick & dirty solution to your problem.
If it were me I would do (1), but in the spirit of "belt + suspenders" I
would probably also do this, if I used an input mask at all (see below).
3) Do not use an input mask at all. Instead, use some combination of
Clock.Read, MouseDevice.GetCursorPos, SlideState.HitTest, and
Context.SetAttrib to directly handle the mouse responses (see those
topics in the E-Basic Help facility). This takes considerably more
programming work, but I find it much more adaptable, and I now take this
approach myself (I have written my own extensive routine library for
this purpose, which I might make publicly available some time).
(Technical aside: You could also just disable the logging from stimulus
Slides, and do that (c.SetAttrib) from your InLine response code
immediately after getting a valid response. You see, when you enable
logging from the GUI, E-Prime sets the logged attribute from the value
that it finds at the *end* of the Procedure, which causes your problem.
If you set the attribute right after getting the response, and do
*not* let E-Prime later override that, then all will work as you like.
But if you take this approach then you are asking for trouble when
someone works with the program later -- at least, add extensive comments
in an InLine to explain what you are doing & why!)
---------------
David McFarlane
E-Prime training online:
http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)
Elif yüvrük
Mar 25, 2016, 8:22:32 AM3/25/16
to e-p...@googlegroups.com, David McFarlane
Mr. McFarlane,
You are right!
Firstly, thanks for your support and guidance! It's very helpful to me.
As you recomended to me, I tested the program adding “RTtime” and as you said ,exactly, all RTTimes are the same within the each procedure.
As I mentioned before, I’m new in using E-Prime and writing codes. So, trying to test solutions that you explained me will take some time for me.
As far as I understand, I can get correct RTs by substracting “next trial” from “previous trial” (maybe using Excel as a primitive solution) .
i.e., To get first RT, second RT minus first reaction time (1st RT = (1st RT) – (2nd RT)) and to get second RT, third RT minus second RT… This formula can be used until the last trial and finally on the last trial, RT is already correct. Am I wrong ?
I know, using this type of calculation after the data collection can give accurate result but not a appropriate solution. Unfortunately, I must immediately begin to collect data due to time constraint.
At the same time I will work on solving problem with E-Prime as you suggest, and If I accomplish, I will get back to you as soon as possible. (via E-Prime forum)
Best regards,
Elif.
--
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/RfGNoNKFWnM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/56F410D3.8090700%40msu.edu.
Arş. Gör. Elif Yüvrük
Ege Üni. Psikoloji Böl. / Deneysel Psikoloji ABD
David McFarlane
Mar 25, 2016, 2:14:18 PM3/25/16
to Elif yüvrük, e-p...@googlegroups.com
Elif,
Nice idea, but only if you can accept calculated RT values that may be
too long by up to, say, 20 ms. Let's look at the math ...
Recall that, for any stimulus object s,
s.RT = s.RTTime - s.OnsetTime
For your existing program, we have
s1.RTTime = s2.RTTime = ... = s12.RTTime
Let's use sn.RTTime to represent any of those.
So when we subtract two of your successive RT values, we get
s1.RT - s2.RT
= (sn.RTTime - s1.OnsetTime) - (sn.RTTime - s2.OnsetTime)
= s2.OnsetTime - s1.OnsetTime
So strictly speaking, we get the difference between the two OnsetTime
values, *not* the RT value. Again, you may test this for yourself by
logging the OnsetTime values for your stimuli, and see if the
calculation comes out as I describe.
But if we assume that the OnsetTime of the next stimulus object is the
same as the actual RTTime of the previous stimulus, then we may get
s1.RT - s2.RT
= s2.OnsetTime - s1.OnsetTime
= s1.~RTTime~ - s1.OnsetTime
= s1.~RT~
using "~...~" to indicate those values are approximate.
Of course, s2.OnsetTime will almost certainly be later than the response
to s1 for a variety of reasons (waiting for screen refresh, processing
time to start next stimulus, etc.). But it may be close enough for your
purposes.
Still, best to fix the program to get actual, correct RT values before
you run any more subjects.
Best,
-- David
On 2016-03-25 8:22 AM, Elif yüvrük wrote:
> Mr. McFarlane,
>
> You are right!
>
> Firstly, thanks for your support and guidance! It's very helpful to me.
>
> As you recomended to me, I tested the program adding “RTtime” and as you
> said ,exactly, all RTTimes are the same within the each procedure.
>
> As I mentioned before, I’m new in using E-Prime and writing codes. So,
> trying to test solutions that you explained me will take some time for me.
>
> As far as I understand, I can get correct RTs by substracting “next trial”
> from “previous trial” (maybe using Excel as a primitive solution) .
>
> i.e., To get first RT, second RT minus first reaction time *(1st RT = (1st
> RT) – (2nd RT))* and to get second RT, third RT minus second RT… This
Nice idea, but only if you can accept calculated RT values that may be
too long by up to, say, 20 ms. Let's look at the math ...
Recall that, for any stimulus object s,
s.RT = s.RTTime - s.OnsetTime
For your existing program, we have
s1.RTTime = s2.RTTime = ... = s12.RTTime
Let's use sn.RTTime to represent any of those.
So when we subtract two of your successive RT values, we get
s1.RT - s2.RT
= (sn.RTTime - s1.OnsetTime) - (sn.RTTime - s2.OnsetTime)
= s2.OnsetTime - s1.OnsetTime
So strictly speaking, we get the difference between the two OnsetTime
values, *not* the RT value. Again, you may test this for yourself by
logging the OnsetTime values for your stimuli, and see if the
calculation comes out as I describe.
But if we assume that the OnsetTime of the next stimulus object is the
same as the actual RTTime of the previous stimulus, then we may get
s1.RT - s2.RT
= s2.OnsetTime - s1.OnsetTime
= s1.~RTTime~ - s1.OnsetTime
= s1.~RT~
using "~...~" to indicate those values are approximate.
Of course, s2.OnsetTime will almost certainly be later than the response
to s1 for a variety of reasons (waiting for screen refresh, processing
time to start next stimulus, etc.). But it may be close enough for your
purposes.
Still, best to fix the program to get actual, correct RT values before
you run any more subjects.
Best,
-- David
On 2016-03-25 8:22 AM, Elif yüvrük wrote:
> Mr. McFarlane,
>
> You are right!
>
> Firstly, thanks for your support and guidance! It's very helpful to me.
>
> As you recomended to me, I tested the program adding “RTtime” and as you
> said ,exactly, all RTTimes are the same within the each procedure.
>
> As I mentioned before, I’m new in using E-Prime and writing codes. So,
> trying to test solutions that you explained me will take some time for me.
>
> As far as I understand, I can get correct RTs by substracting “next trial”
> from “previous trial” (maybe using Excel as a primitive solution) .
>
> RT) – (2nd RT))* and to get second RT, third RT minus second RT… This
Reply all
Reply to author
Forward
0 new messages