scoring a nonresponse as a correct answer

[David McFarlane]

Jim,

>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)

-- 
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.