scoring a nonresponse as a correct answer
Jim
I sent this question to e-prime support last week; unfortunately, they
are experiencing high volume and have been taking a long time to get
back to my requests. They are time sensitive, so I was hoping the
forum might have some ideas.
I'm working with an e-prime experiment where participants are asked to
press a button ("7") whenever they see a letter except for "X" (at
which point they are asked to withold a response). I have a column in
my task list "CorrectAnswerL" which states "7" for any letter (another
column in the task list) other than X; CorrectAnswerL is blank for
trials with "X"s. In the procedure associated with that list, the
stimulus "LetterPresentation" has [CorrectAnswerL] listed in the
"Correct" blank in the "Duration/Input" tab. When I run the task,
nonresponses are not scored as correct for X trials (that is,
LetterPresentation.ACC = 0).
I previously had the task running with an inline script following the
stimulus and a blank pane "ISI" which stated:
If LetterPresentation.RESP = c.GetAttrib ("CorrectAnswerR") OR
LetterPresentation.RESP = c.GetAttrib ("CorrectAnswerL") Then
LetterPresentation.ACC = 1
End If
At this time there were two correct responses which is why there is an
additional "correctanswer" attribute. This is no longer the case, and
I want to remove the inline code. However, when I was using this code,
nonresponses were scored as correct for X trials. Please let me know
how I can have nonresponses scored as correct for X trials without
using inline code.
As an aside, I removed the inline code because I am concerned that it
will be executed too early. Each trial consists of the presentation of
a letter (250ms), and subsequently a blank screen (1000ms)- both
objects have a 100ms prerelease. Once the letter is presented,
participants have until the end of the blank screen (1250ms later) to
make a response. I prevously had the inline script following the blank
screen object ("ISI"). I've been reading the critical timing chapter
of the eprime manual which made me concerned that if participants made
a response between 1150 and 1250ms their response will not be scored
with inline code because of the 100ms prerelease on the blank screen.
A complicating factor, is that I can't change the timing of the task
whatsoever, it has an associated fMRI program that it must be tightly
timed with.
Thanks,
Jim
ben robinson
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-p...@googlegroups.com.
To unsubscribe from this group, send email to e-prime+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.
David McFarlane
First, your earlier designed used what I call "multiple correct
response targets". By way of background, if you search this Group
using terms like that then you will find where we have discussed
several approaches to that.
Second, I wonder if something else is going on in your program? I
myself have used a blank [Correct] to score the accuracy of
no-response trials (where the absence of a response is correct and
any other response is incorrect) and that worked fine for me. It
should just work for you.
Third, you might want to study Chapter 3 further to better understand
the intricacies of PreRelease. Sadly, PST does not do a very good
job of explaining it, and in fact the whole PreRelease mechanism
provides much more granularity than users need or want (should be
just on or off -- whenever I use PreRelease I just set it to some
arbitrarily large value, often larger than the Duration, with no ill
effects). For instance, if you do not use the .ACC within the trial
itself (only to log it) and know the response will come before the
onset of the final object in trial Procedure, then you can safely use
PreRelease with abandon and then use inline code after the final
object to score the .ACC if needed.
Fourth, whenever I teach E-Prime for fMRI, I first briefly explain
the difference between Event and Cumulative timing. Then I just lay
down the law and tell students, for fMRI, just make things easy and
set *every* object to Cumulative timing!! Yes, I know that is
excessive, but I have yet to find a case where Cumulative timing
creates a problem, whereas Event timing is known to create problems
in several contexts. If it were up to me I would just make
Cumulative the default and then only allow users to choose Event mode
if they think it really applies to their study (back when I wrote
everything in C I did everything in what E-Prime calls "Cumulative"
timing mode, it just seemed cleaner and took no real programming effort).
-- David McFarlane, Professional Faultfinder
Jim
response, it seems like there is something wrong with my task and that
it should be able to correctly score nonresponses without inline code.
David:
"I myself have used a blank [Correct] to score the accuracy of
no-response trials (where the absence of a response is correct and
any other response is incorrect) and that worked fine for me."
By reading the description above of my experiment, do you have any
leads as to what might be causing the no-response trials to be
incorrectly scored? I'm stumped.
"For instance, if you do not use the .ACC within the trial
itself (only to log it) and know the response will come before the
onset of the final object in trial Procedure, then you can safely use
PreRelease with abandon and then use inline code after the final
object to score the .ACC if needed."
Unfortunately, I don't think this will be helpful because the final
object in the trial procedure is still logging participants responses.
For this particular experiement, the trial procedure consists of a
letter (250ms), and subsequently a blank screen (1000ms); participants
responses are logged during both of these objects. For my other
experiments, the inline scoring code is used in the trial itself.
One related question/clarification: I am assuming that if there is no
inline scoring code that prerelease doesn't interfere with data
logging. Is this a correct assumption?
Thanks,
Jim
> >Jim- Hide quoted text -
>
> - Show quoted text -
ben robinson
Michiel Spape
Speaking before my turn, but I thought perhaps the only issue you have is due to a 'pending' response, which is not exactly the same as an inaccurate or accurate response. Does the display to which you have an accurate or inaccurate response perhaps one that has a certain time limit? If I have a simple screen with time limit 10000 ms and duration 100 ms, for example, this is logged as ACC = 0 (just tested).
Cheers,
Mich
Michiel Spapé
Research Fellow
Perception & Action group
University of Nottingham
School of Psychology
Thanks,
Jim
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-p...@googlegroups.com.
To unsubscribe from this group, send email to e-prime+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.
This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
David McFarlane
verify this for myself, and as you outlined, if
the Time Limit extends around to the next use of
the same object, then E-Prime never gets to score
the non-response and .ACC gets stuck with the
default value of 0. Whenever I have used
non-responses in the past of course I used either
self-paced trials with End Action = Terminate, or
I had better contained Time Limits, so I never
noticed this until you mentioned it.
Jim -- Ben's response refers to the use of what
PST calls "Extended Input", you can learn about
that in Appendix C of the User's Guide that came
with E-Prime. If you do not do this already,
then only the letter object should collect the
response, throughout its Duration and the
Duration of the following blank period, using
Extended Input (i.e., setting Time Limit to the
sum of both Durations). If you cannot use a
constant Time Limit then you will need some code to set it each time.
Also, as explained in Chapter 3, PreRelease *can*
interfere with data logging even if there is no
inline scoring code, in particular if you get a
response during a PreRelease right at the end of
a Procedure. E.g., if your final
stimuls/response object has a Duration of 1000 ms
and a PreRelease of 200 ms, then E-Prime will run
the object for just 1000 - 200 = 800 ms and then
move on log responses, end the trial procedure,
prepare the next object (i.e., the first object
of the next trial) and then wait for the new
object's .TargetOnsetTime. If your subject
responds during that final 200 ms PreRelease
window then it comes *after* responses have
already been logged and will not be logged
itself. So please read through that section
again. Understanding PreRelease gets tricky, and
I try to give beginners some rules of thumb such
as, (1) if your Procedure collects a response,
then do not use PreRelease, (2) if your
Procedure does *not* collect any response then
feel free to use any PreRelease that you
like, (3) if you do use a PreRelease, don't
bother overthinking it, just make it some
arbitrarily large value. This is Draconian, and
may well lead to some timing inaccuracies, but in
general we fear losing responses more than we
fear bad timing, and we can deal with the timing
issues just for those cases where it matters.
Finally, I will repeat that no one should ever
take my word (much less the E-Prime
documentation's word!) for anything -- you should
think up as many specific test cases as you can
and make as many short demo programs as you need
to convince yourself of how things really
work. All we can do here is give you a few hints of paths to try.
-- David McFarlane, Professional Faultfinder
Jim
response window duration of 1250ms just as you said. On this
particular task, I don't want to mess with pre-release because the
scanner paradigm has already been used/validated by someone in my lab
with 100ms prerelease on every object. I just want to figure out how
to score non-response without inline code (the person who used the
task before me did not log responses).
Michiel: I'm not following you, so I will give more detail about the
procedure of the task and maybe this will answer your question. Each
trial presents a letter in the middle of a black screen for 250ms
(with a response window duration of 1250ms) followed by a black screen
(with no letter) for 1000ms.
Thanks!
Jim
> > e-prime+u...@googlegroups.com<e-prime%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/e-prime?hl=en.- Hide quoted text -
Jim
I think I understand Mich's response now. Essentially, there needs to
be a gap between the end of the response interval of a given stimulus
and the presentation of the next instance of the same stimulus? What
would be the least disruptive way to change my task so that non-
responses are correctly logged (e.g., should I change the response
duration to 1249ms)? Also just to make sure I'm clear on this, Is this
problem related to the fact that my objects have 100ms of prerelease
or is this a totally separate issue?
I read the timing chapter twice and the prerelease section more than
that; unfortunately I am still very confused. Your general guidelines
help. From your description, it really seems like one should not use
prerelease if they are logging responses. Or I'm just misunderstanding
you :)
Also, David, I wanted to give an update on my other posting that you
responded to here (the one that has a task with feedback synching with
physio data collection). I tried setting all objects to cumulative
mode. Timing was relatively repeatable accross runs (give or take a
millisecond); however, when I responded to the stimuli instead of just
letting the task run without responses, the timing was not repeatable
(30-50ms off). I am not using prerelease with this task; participants
are given feedback and I don't want it to interfere. Any ideas?
Thanks,
Jim
> ...
>
> read more »- Hide quoted text -
David McFarlane
>I don't want to mess with pre-release because the
>scanner paradigm has already been used/validated by someone in my lab
>with 100ms prerelease on every object.
That 100 ms PreRelease is almost certainly an artifact of E-Prime
defaults, and not a deliberate choice on the part of your
developer. When you switch an object from Event to Cumulative timing
mode then EP automatically imposes a default PreRelease of 100 ms,
and unless the developer edits that then that is what you get left
with whether it helps or not.
As an exercise, you definitely should try setting PreRelease to 0 and
then test the timing/sychnonization for yourself. <rant>Even without
changes, you must personally shake down every program you use, I
don't want to repeat the horror story we had here a few years
back. If it takes you half an hour to sit through a timing
verification run, then so be it, although with some cleverness you
can speed things up using Clock.Scale. But in any case, you must,
MUST personally shake down every program you use. I cannot stress
that enough. And as long as you are shaking down that program, you
might as well try some changes and learn a few things. Above all, do
NOT get into a rush -- as my own graduate advisor told me many years
ago, scientific research is a deliberative process and not a business
to be done in a rush. Or have the times changed that much?</rant>
Jim
presentation of the subsequent stimulus) and nonresponses are still
being incorrectly scored as ACC=0. ???
David McFarlane
>I think I understand Mich's response now. Essentially, there needs to
>be a gap between the end of the response interval of a given stimulus
>and the presentation of the next instance of the same stimulus? What
>would be the least disruptive way to change my task so that non-
>responses are correctly logged (e.g., should I change the response
>duration to 1249ms)?
Hmm, even if that worked I think there is a better way.
> Also just to make sure I'm clear on this, Is this
>problem related to the fact that my objects have 100ms of prerelease
>or is this a totally separate issue?
Quite likely related, the more I understand your program.
>I read the timing chapter twice and the prerelease section more than
>that; unfortunately I am still very confused. Your general guidelines
>help. From your description, it really seems like one should not use
>prerelease if they are logging responses. Or I'm just misunderstanding
>you :)
No, you got that right. I would start with all PreRelease set to 0,
and then add PreRelease only as needed. And instead of doing this in
my actual experiment program, I would start with a lot of little demo
programs as exercises to first test my understanding. Cumulative
mode should do everthing you need to make sure that your task program
stays more or less in sync with external equipment (brain scan,
etc.), even in the presence of large OnsetDelays (in fact I have
sometimes deliberately taken advantage of that fact); PreRelease
contributes nothing to synchronizing with external equipment, and
comes into play only when you need to reduce individual OnsetDelays,
and even then some cases require techniques that go beyond PreRelease
(preloading/caching, etc.). So leave PreRelease at 0 until you know
you need it, and know *why* and *where* you need it.
>I tried setting all objects to cumulative
>mode. Timing was relatively repeatable accross runs (give or take a
>millisecond); however, when I responded to the stimuli instead of just
>letting the task run without responses, the timing was not repeatable
>(30-50ms off).
That's just weird. Unless... unless you have End Action = (none) or
Jump anywhere, then all bets are off. But then you should also get
off by much more than 30-50 ms. Or unless you have some inline code
messing with TargetOnsetTime, or skipping past some objects, but
short of that, with Cumulative Timing everything should Just Work
regardless of responses. So maybe it's time for you to take this to
a local expert who can look at the program, or send it back to your
collaborator and have their developer fix this.
David McFarlane
>FYI, I set the response duration as 1150ms (100ms prior to the
>presentation of the subsequent stimulus) and nonresponses are still
>being incorrectly scored as ACC=0. ???
You need to stop working on the actual experiment program. Before
you do anything else, make a simple demo program with a List and a
Procedure with one TextDisplay, have it take some input and leave
Correct empty, then run it and see that you get .ACC = 1 for
nonresponses. If you cannot get that to work then nothing else
matters. Once you do get that to work you can extend it along the
lines of your experiment until you figure out what is going on.
As a general strategy, I find it more productive to start from
success than from failure -- easier to start with a simple and easily
understood working model and find what breaks it than to start from a
complex broken model and find what fixes it.
Jim
everything else in tact, I tried some things:
1) I tried turning prerelease off on all objects, this didn't solve
the problem
2) As I noted previously, I tried shortening the response duration to
1150, also didn't solve the problem
3) Did both 1 and 2 simultaneously, and nonresponses were correctly
scored ACC = 1.
**So the problem is an interaction of prerelease and response duration
However, shortening the response duration really defeats the purpose
of why I removed the inline code. Specifically, I was concerned that
having the inline code (and having the previous object with a
prerelease of 100ms) meant that the inline would be executed 100ms
before the end of the response period. So,
4) I turned all prereleases off, inserted my scoring inline code,
nonresponses were correctly scored.
So, now a question about inline code: how much time does it add to
each trial of my task to run the inline code (and does this amount of
time increase depending on the length of the inline code script)? My
task currently has each trial as a) stimulus (250ms with 1250ms
response window), b) blank screen (1000ms), c) inline scoring code. My
questions:
1) Does adding the inline code increase the duration of the overall
task (does the magnitude of this increase in duration depend on the
length of inline code)?
2) Does adding inline code cause responses to be logged and scored
prior to the termination of the 1250ms response window? (If so, how
much)
3) To clarify your earlier point, David, I am assuming that removing
all prereleases shouldn't change the overall duration of my task, just
the magnitude of onset delays, right?
By the way, this discussion has been, and continues to be,
tremendously helpful in my learning about e-prime as a new user!
Thanks,
Jim
David McFarlane
>1) Does adding the inline code increase the duration of the overall
>task (does the magnitude of this increase in duration depend on the
>length of inline code)?
As I have said recently in another thread, you might be surprised at
just how much code modern machines can run in under a millisecond. I
once wrote a complete & inefficient Maximum Liklihood Estimation
staircase program in EP code that did dozens of logarithmic
calculations and multiplications between each stimulus, and noticed
no delays at all. Most time bottlenecks these days are not due to
running code, but to loading files from the disk or interruptions
from the operating system. So in principle, yes, the more code you
add the more you will add delays, but in practice, unless you run
actual timing delay loops or sleep commands, I highly doubt you will
see any difference. And once again, you should devise your own tests
to see if I know what I am talking about.
More importantly, even in the worst case of delays added from inline
code, Cumulative mode will *still* provide the proper
.TargetOnsetTimes. It *must*, because it is just simple arithmetic,
as I explain below.
>2) Does adding inline code cause responses to be logged and scored
>prior to the termination of the 1250ms response window? (If so, how
>much)
Note first that scoring, setting, and logging are all different
things. Scoring happens either internally by the object, or
externally when you add inline code such as
If StimText.RESP = "1" Then StimText.ACC = 1
What I will call "setting" (lacking a better term on the spur of the
moment) happens when you or E-Prime adds code such as
c.SetAttrib "StimText.ACC", StimText.ACC
This sets the value of an attribute which can then be
logged. Finally, logging happens with the line
c.Log
This line gets added silently & automatically at the end of every
Procedure (unless you disable that, which is by design hard to
do). Go ahead, look at the full generated code and see if you can
find the c.Log just before the End Sub of every Procedure. So you
can have c.SetAttrib change the value of any attribute wherever and
as many times as you like within a Procedure, but it will get logged
using the latest value only at the end of the Procedure.
So in answer to your question, if your scoring inline takes place
before the response then the response may not get properly scored;
all input masks will get logged at the end of the Procedure, whether
or not a response has come by then and notwithstanding any nonsense
that goes on in intervening inline code; and inline code cannot "log"
(as opposed to score) responses prematurely unless you deliberately
add the c.Log line yourself, in which case you are just asking for
trouble (unless you are an E-Prime Master and really know what you are doing).
>3) To clarify your earlier point, David, I am assuming that removing
>all prereleases shouldn't change the overall duration of my task, just
>the magnitude of onset delays, right?
As long as you set everything to use Cumulative timing mode, yes,
that is correct. It has to be, because of the laws of arithmetic and
the simple arithmetic relationship between consecutive
.TargetOnsetTimes (which PST fails to properly explain). Taking the
simple case of Cumulative timing where objects never get terminated
by a response, given two objects A and B where B follows A (whether
within the same Procedure or on the following trial, and where B may
in fact just be a repetition of A), then the following simple relation holds:
B.TargetOnsetTime = A.TargetOnsetTime + A.Duration
Note that PreRelease and actual OnsetTime (let alone OnsetDelay) play
absolutely *no* role in this calculation. Thus, in this simple case,
the timing synchronization of .TargetOnsetTime (which is all that we
can really control) absolutely *cannot* drift.
Now, PreRelease simply advances the .OffsetTime of objects, thus,
A.TargetOffsetTime = A.TargetOnsetTime + A.Duration - A.PreRelease
Note that neither A.TargetOffsetTime nor A.OffsetTime control when B
will start, that is controlled only by
B.TargetOnsetTime. A.TargetOffsetTime simply controls when E-Prime
ceases the idle loop that runs during A, and allows the processor to
do some other work (e.g., run inline code, or load image or sound
files). B will not start until the Clock reaches B.TargetOnsetTime,
regardless of how early A.TargetOffsetTime comes. Finally, if by
some quirk E-Prime does not get to B until the Clock is already past
B.TargetOnsetTime, B will just start immediately, and (in Cumulative
mode) B.TargetOffsetTime (as well as, now, C.TargetOnsetTime) will
still just be A.TargetOnsetTime + A.Duration. Follow? (This is in
fact an advanced trick that I take advatage of in some
programs.) Again, this is just elementary arithmetic, nothing
magic. (And if you understand the underlying mechanics like I do,
you will see how silly this whole PreRelease mechanism is, but that
is another matter.)
And once again, do NOT take my word, or even PST's word, for *any* of
this. You really have to knuckle down, make a bunch of small demo
programs for yourself, turn on logging of *everything*, start making
changes and see for yourself how all these parameters really affect
all the timing measures. How do you think *I* figured this all
out? I certainly did not get it from reading PST's documentation
(Chapter 3 notwithstanding), nor did I get it from reading the online
posts of some random self-styled "Faultfinder" like me.
-- David McFarlane, Professional Faultfinder
"You got to test that piece of software, You got to test it for yourself,
No one else can test it for you, You got to test it for yourself."
(Apologies to the Fairfield Four)