Conditional Branching in Builder

[C. Luhmann]

Hey folks,

I have been using PsychoPy for a while now and have just dipped my
toes into the world of the Builder front-end. I was wondering if
there was a way to do conditional branching from within the Builder
interface. Nothing jumped out at me, but I've only just begun to poke
around. I thought that the "code" component might be useful, but
wasn't quite sure whether/how one could call Builder routines using a
snippet of raw Python.

If this isn't currently possible, are there plans to incorporate such
capabilities in the future?

Thanks.

[Jonathan Peirce]

It isn't currently possible. My gut reaction is that that could get
really complicated really quickly. Hard to make intuitive and clear. Nor
am I sure how to draw it cleanly (in the current Flow panel things are
conveniently restricted to one dimension, btu I fear you're suggesting
going beyond that.)

But you *can* use a linear flow and simply change what occurs, using a
code component.
As an example see the attached experiment, it's the stroop again (my
favourite demo task ;-) ), but more complete, with practice trials and a
feedback routine. That feedback routine contains a message that's
conditional on the response of the previous routine using a code component:
"Oops, you goofed!"
or
"Well done! Your RT was xx.xx secs"
(could make it red or green too for impact, but I haven't done)

So I guess the question is, how different do the contents of your
conditional branches need to be?

Jon

--
Dr. Jonathan Peirce
Nottingham Visual Neuroscience

http://www.peirce.org.uk/

[C. Luhmann]

Yes, I definitely could see this sort of thing getting out of hand. I
figured that there was some way to use the code component to change
"small" things as your Stroop example.

Would another workaround would be to wrap contingent routines in dummy
loops and then use a code component to dynamically set the various
nReps parameters to either 1 (if you want that routine to execute) or
0 (if you don't want that routine to execute)? If so, that would
probably provide about as much flexibility as one could reasonably
expect.

Thanks.

>  stroop.zip
> 53KViewDownload

[Jonathan Peirce]

Good thinking, yes, that could be an interesting way to 'hack' some
form of branching. The slight issue is that it would require the loop (a
TrialHandler) to be created immediately before running the loop, whereas
my natural inclination was to create it at the top of the script.
Although top of the script was the natural choice, I can't think of any
reason that it actually *needs* to go there.

In short, that won't work right now. But I think it could do one day,
probably with very little effort on my part ;-)

Jon

[Gary Strangman]

For what it's worth, I believe the nReps "hack" is available and a typical
branching approach used in Eprime, and works pretty well.

Gary

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Jonathan Peirce]

you mean, what I consider a slightly ugly hack, is ePrime's
recommended method...?
;-)

Could you send me an idea of a study that would actually use this
feature? Then I'll ensure that it's possible and include a demo.

jon

[Gary Strangman]

I can't say for sure that's Eprime's recommended method, but I've seen
that feature used for precisely this purpose. ;-)

A simple case is an experiment that has a training phase and a testing
phase. Perhaps you train to criterion, then test over multiple sessions.
In later sessions, you might want to skip the training (i.e., set weight
or nReps equal to 0). Limited branching could thus be achieved, as long as
you had control over the nReps variables. Conceptually, something like:

# ==== code fragment ===
# enable setting of nTrainingReps up here (Eprime does it via a dialog box
# that lets you set weights for all the experiment components on your
# timeline)
while nTrainingReps>0:
# do a training run
(CODE FOR ONE RUN OF THE TRAINING PHASE)
(GENERATES A performance VALUE, RANGE 0-1)
if performance>0.9: # if they did well enough, quit looping
nTrainingReps = 0
else: # otherwise keep looping until preset number of reps
nTrainingReps -= 1

# you could even compute nTestReps in here based on, oh, accuracy or RT or ...

while nTestReps>0:
# do a testing run
(CODE FOR ONE RUN OF THE TESTING PHASE)
nTestReps -= 1
# ==== end code fragment ===

That is, generate some wrapper loops around Builder elements, with
assocaited "Reps" variables (Eprime calls these "weights") that can then
be manipulated by in-line code for skipping sections, repeating sections,
etc. Others assuredly have better experimental examples for using this,
but I found it pretty useful for examples like the above in Eprime (once I
was introduced to the concept). It made for easy experiment testing too,
as you could "skip" large sections of the experiment (set weights to 0)
while testing some other phase of the experiment ...

G

[Jeremy Gray]

another example: I wrote a version of the Iowa Gambling Task about 12 years ago. if I were to rewrite it in PsychoPy, I would probably use conditional execution a fair bit. the subject clicks on 1 of 4 decks of cards, and different outcomes ensue, depending on the deck selected each trial. it might be possible to get by with only code components and parameterize everything, but it might not be possible and it would probably be easier to use a nReps-like on/off switch.

--
You received this message because you are subscribed to the Google Groups "psychopy-users" group.
To post to this group, send email to psychop...@googlegroups.com.
To unsubscribe from this group, send email to psychopy-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/psychopy-users?hl=en.

[Jonathan Peirce]

Right. Got it. Gary's example was just what my grey matter needed ;-)

Actually a colleague had asked that the loops could receive nReps=0 for
this purpose but in the dlg, not inline, and there is a fix in the git
repository to cope with that. The problem with changing it on the fly is
that nReps needed during init of the TrialHandler and shouldn't change
thereafter.

But your example below gave me the idea that things should be able to
quit during a loop as well (you could set nReps to 1000 and exit the
loop on a performance criterion instead). So, the fix is to have an
attribute of loops called .finished and if that ever gets set to True
(either before or during repeats) then the loop will exit at the
beginning of the next iteration.

If you want to play with it you need to fetch the new data.py from the
'raw' link in the repository here:
http://github.com/psychopy/psychopy/blob/master/psychopy/data.py
*NB: the source code has moved from google to github.com*

The attached file shows how to use the feature (the code component in
the `instr` Routine)

all the best,
Jon

[Jonathan Peirce]

PS. the line in the code component of the previous post that says
letterColor=red #to initialise
isn't necessary (I was trying another approach that i didn't like so much).

Jon