scoring a nonresponse as a correct answer

Tue Feb 23 16:57:48 UTC 2010

Hi,
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

-----Original Message-----
From: e-prime at googlegroups.com [mailto:e-prime at googlegroups.com] On Behalf Of Jim
Sent: 23 February 2010 16:00
To: E-Prime
Subject: Re: scoring a nonresponse as a correct answer

Ben: Thanks, this is a creative solution. However, as per David's
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

On Feb 22, 5:52 pm, David McFarlane <mcfar... at msu.edu> wrote:
> Jim,
>
> 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
>
> At 2/22/2010 11:17 AM Monday, you wrote:
>
>
>
> >i think you'll need to use an inline to do this, but i also think
> >you can mostly avoid the complications introduced by using the prerelease.
> >here's what i would do:
>
> >put your inline after the 1000 ms blank screen, knowing that the
> >inline code may be read as early as 900 ms into the blank screen's
> >duration (and only 1150 ms after onset of your letter stimulus).
> >the script in the inline would be something like this:
> >Do
> >Loop Until (Clock.Read - LetterStimulus.OnsetTime) < (1250 -
> >Display.RefreshDurationStats.Mean)
> >If LetterStimulus.RESP = "" And c.GetAttrib("Stim") = "X" Then
> >LetterStimulus.ACC = 1
>
> >that Do...Loop will loop continuously until there is less than a
> >single screen refresh's worth of milliseconds remaining in the
> >LetterStimulus's response window, at which point the script will
> >kick out of the Do...Loop, check to see if there was no response,
> >and if no response and if 'X' then assign an accuracy of '1' to the
> >LetterStimulus object.
>
> >how's that?
>
> >ben
>
> >On Mon, Feb 22, 2010 at 11:01 AM, Jim
> ><<mailto:jjprisciand... at gmail.com>jjprisciand... at gmail.com> wrote:
> >Hello forum,
>
> >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- Hide quoted text -
>
> - Show quoted text -

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at 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.

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.