Skipped TextDisplay retains previous trial's .RT etc.

Tue Jan 12 10:06:17 UTC 2010

Thanks David M - replacing c.SetAttrib statements with direct assignment 
(eg "DisplayedSometimes.RT = -99") works perfectly; my intended values 
are now correctly logged.

-david v

David McFarlane wrote:
> 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
>

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