duplicate log

[Victor]

Hello,

I was wondering if anyone can tell me why my experiment is logging a
duplicate of the last response please?

The experiment does not have a list. User input forms an array with
which correct responses and experiment duration are then determined on
the fly in an inline script. The experiment has a slide and feedback
object that loops until a criteria is met. Responses are recorded
using the c.log function. However, the last input to the slide is
always duplicated. Could anyone tell me why it does this and if it is
possible to prevent it?

Many thanks for any assisstance.

Tim

[liwenna]

This is probably not it... but... I noticed in another experiment
wherein subjects terminate a trialproc when responding, that for the
slides not shown (i.e. those that would have been shown after the
subject pressed the button) the previous value (from earlier trials
wherein the subject responded later in the trialproc and the later
slides have been shown) are duplicated. Don't worry if you don't
understand the previous sentence... what it boils down to is that if
the last response is not made, e-prime could duplicate the response
from the previous trial.

Now your responses are taken trough an array and arrays have this
nifty thing where they have a level 0. Could it be that if you have
for instance 10 responses you defined the array as 'responses
(10)' (instead of 'responses (9)') which would result in an 11-level
array so that one level stays empty after 10 trials and is autofilled
with the answer from the previous trial?

Just a thought... :)

[David McFarlane]

Tim (or Victor?),

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, my best guess is that the trial procedure adds its own
c.Log at the end, so that all your programmed c.Logs get supplemented
by one final automatically generated c.Log. You can check this
yourself by looking at the full generated script (not just the stuff
in your own inlines), just before the End Sub of any of your defined
Procedures.

Now, I am not sure exactly why that would cause your final extra log
value, because usually extra c.Logs at the same logging level have no
effect (only the final one counts, as I recall), you have to wrap
your c.Logs in c.PushNewFrame and c.PopFrame if you want to log extra
values in the middle of a Procedure. In any case, if you ever do
want to disable the final c.Log of a Procedure, then you have to open
the Procedure's own properties (right-click in the Procedure's open
window and select Properties, or select the Procedure and view its
Properties list) and deselect LogData. Mind you, this is a dangerous
practice, because there is *no* visible indication that logging has
been disabled for that Procedure, and later when someone expects it
to log data they will be totally confounded! So if you ever do
disable a Procedure's logging, I *strongly* urge you to add a
"ReadMe" inline just to add a comment that explains that logging has
been disabled for this Procedure, and how to re-enable its logging.

<editorial>
Not germane to your question, and I don't know that I want to open
this can of worms, but I do wonder why you want to do so much in
script instead of availing yourself of the List features of E-Prime,
seems to me to defeat the purpose of using E-Prime in the first place.
</editorial>

Just a thought,
-- David McFarlane, Professional Faultfinder
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." (Richard Feynman,
Nobel prize-winning physicist)

[David McFarlane]

At 11/20/2009 10:03 AM Friday, David McFarlane wrote:
>usually extra c.Logs at the same logging level have no
>effect (only the final one counts, as I recall), you have to wrap
>your c.Logs in c.PushNewFrame and c.PopFrame if you want to log extra
>values in the middle of a Procedure.

For reasons of my own I explored c.Log further this weekend, and now
I must correct my earlier statement (and that should answer your
question). In fact, except at the Session logging level, every use
of c.Log results in a row added to the .edat file. Only at the
Session logging level (level 1), only the first c.Log counts; later
c.Log statements at the Session logging level do add to the data .txt
file, but those entries are ignored in making the .edat file.

So, in your inline script you have a number of c.Log statements, and
every one of those adds a row to your .edat file. Then the Procedure
adds one more c.Log just before the end, where you never see it
(unless you look at the full generated script, which you should do
now), and that adds one final (duplicate) row to your .edat file,
exactly as it should.

As stated earlier, to avoid this you must either construct your
inline script so that it leaves the final c.Log to the Procedure, or
you must disable the LogData property of the Procedure. Use extreme
caution if you resort to the latter!

Please do write back and let us know how this works for you. As
usual, no one should take my word for anything. Always use your own
reason, and conduct your own tests to satisfy yourself.

[Victor]

Thank you for the input. David you were correct; it was indeed the
procedure data logging that was causing the duplicate log and your
proposed solution worked! Thanks.

Also, an attempted (brief) answer to your earlier comment about using
script - this experiement was a learning exercise for me in terms of
scripting and there may have been easier ways to do this. The
experiment requires the user to input discrete combinations of
numbers. A chosen unique combination is selected as a correct
combination, which is rewarded via feedback on a psuedo-randomised
reinforcement schedule. The structure I chose was to use input from
the user to populate an array based on a series of possible vaild
reponses of which the nth unique is defined as the correct response.
Of the x number of trails, the correct combination is positively
rewarded only on specific trials defined at the start of the
experiment script using a random (non-repeated) number array.

Thanks again,
Tim (although I quite like the alias Victor)