Skipped TextDisplay retains previous trial's .RT etc.

[David McFarlane]

David,

Standard reminder:  1) I do not work for PST.  2) PST's trained staff 
really does like to take any and all questions at 
http://support.pstnet.com/e%2Dprime/support/login.asp , and they 
strive to respond to all requests in 24-48 hours.  So don't be shy 
there.  3) If you do get an answer from PST Web Support, please 
extend the courtesy of posting their reply back here for the sake of others.

That said, here is my take ...

Gosh, I love these little puzzles that are so nicely described, so I 
just had to try it out with my own little "toy" demo and indeed, I 
recreated the problem handily.  And this nicely illustrates a bit of 
the structure of the script that E-Studio automatically generates for us.

If you look at the full script generated for your program, you will 
see that it adds a bunch of lines like

c.SetAttrib DisplayedSometimes.Name & ".RT", DisplayedSometimes.RT

just before the final c.Log and End Sub of your Procedure.  Note that 
this script gets inserted *after* any of your objects and script in 
your Procedure, and before the end of the Procedure, and there is 
almost nothing you can do about it.

So, your inline script directly changes attributes using ordinary 
c.SetAttrib statements, but does not change the underlying properties 
of your DisplayedSometimes object from its last occurrence.  Then you 
use a c.Log in script, which dutifully logs your scripted 
values.  Then the program dutifully moves on to replace your scripted 
attribute values with values from the DisplayedSometimes properties, 
which still hold its values from the last occurrence.  And then 
E-Prime logs all that again.  Whew!

To avoid this, I would *not* use c.SetAttrib in this case.  Instead I 
would have my script simply change the actual DisplayedSometimes.RT, 
etc. properties, and then let the automatically generated script take 
care of the rest for me.  In general, I use c.SetAttrib only for 
attributes that do not belong to a stimulus/input object.

BTW, I did say that that there is almost nothing you can do about 
that c.SetAtrib script that E-Studio adds at the end of your 
Procedure.  But of course you could turn off logging for any desired 
stimulus objects, and then your own c.SetAttrib script would work as 
expected.  But I deem this a poor practice.

<editorial>
As indicated at the start, I wholeheartily approve of posting issues 
both to PST Web Support and this Group simultaneously, as you 
did.  And if anyone wants to get the attention of this Professional 
Faultfinder then they do best by posting here on the E-Prime Google 
Group rather than on the PST Forum.  The Forum gets too easily 
confused with Web Support, and otherwise merely duplicates the 
function of this Group, so I have been limiting my own activities on 
the Forum in favor of this Group.
</editorial>

-- David McFarlane, Professional Faultfinder
"When all is said and told, the 'naturalness' with which we use our 
native tongues boils down to the ease with which we can use them for 
making statements the nonsense of which is not obvious."  -- Edsger 
W. Dijkstra, "On the foolishness of 'natural language programming'" 
(http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html)


>Dear E-Prime group,
>
>I am working on an E-Prime 2.0 experiment, with a procedure that 
>contains one or two response objects - display of the second one 
>only happens on some trials. The problem is that "old" trial data 
>are retained for those trials for which the second response is 
>skipped. I'm sure there's a simple solution but I've thought myself 
>into a corner on this one!
>
>Here is a brief description of a toy version of the experiment which 
>exhibits the same problem:
>-----------------------------------------------------------------------------------------------
>We have a list Object which calls a single procedure including the 
>following main elements:
>
>1. TextDisplay "Displayed every time" which appears on every trial, 
>with standard data logging.
>
>2. Inline "Check for skip" - 40% of the time the second textdisplay 
>will not appear, instead setting a "Skipped" variable and skipping 
>to a label after the second text display.
>
>3. TextDisplay "Displayed sometimes", with standard data logging.
>
>4. Label "Skip second",
>
>5. Inline "Cleanup" which uses c.SetAttrib to set 
>DisplayedSometimes.RT to -99 (and other such attributes/values) only 
>if the Skipped variable is set.
>
>-----------------------------------------------------------------------------------------------
>When the experiment runs, this works as desired, skipping the second 
>text display approx 40% of the time.
>
>Our problem is in the data file. Assume that DisplayedSometimes 
>occurred on trial N, thus generating real RTs etc for that trial, 
>and that DisplayedSometimes was skipped on trial N+1 (and thus 
>DisplayedSometimes.RT should be -99). Instead, we find that the same 
>values are logged from the last time they were collected (e.g. if 
>.RT was 555 on trial N, it will appear as 555 for trial N+1, and so 
>on until DisplayedSometimes occurs again).
>
>If we add a c.Log to the "Cleanup" inline, this creates two entries 
>for trial N+1 in the data file. The first entry contains our desired 
>values (.RT of -99), The second entry, however, contains values from 
>trial N, e.g. .RT of 555).
>
>Is there any way to clear/flush the previous trial data from objects 
>like DisplayedSometimes in the example here? (or otherwise correctly 
>assign NULL or some identifiable "skipped" value like the example of 
>.RT = -99 to those trials)?
>
>We have considered the possibility of calling two different 
>Procedures (one with a single TextDisplay and the other with both), 
>but haven't found a suitable solution as in our actual experiment, 
>the decision to skip or not is partially contingent upon the 
>response made to the first.
>
>I'd be grateful for any advice - can supply a toy version of the 
>experiment if my verbal description is confusing!
>
>(I have submitted a request to PST support but thought I would risk 
>a concurrent submission to the group after seeing the "We are 
>currently experiencing a large volume of requests..." message on the 
>support site!).
>
>
>Thanks,
>David
>
>--
>David Vinson, Ph.D.
>Postdoctoral Researcher
>Deafness, Cognition and Language Research Centre (DCAL)
>University College London
>49 Gordon Square, London, WC1H 0PD
>Tel +44 (0)20 7679 8688
>d.vinson at ucl.ac.uk

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