Help with Cognition Single-Task Organization

[Sommer Martin]

To give a layout for our experiment:

 A participant will be shown an image that displays three rectangles in
 any configuration of three colors (blue, green, and/or black) and
 orientations (vertical, horizontal, 45 degree tilt), very briefly. Then
 they will be shown a neutral nature scene for 15 seconds. A tone will
 sound at the end of the 15 seconds and then they will be shown another
 image displaying three rectangles in any kind of configuration. They
 have to state [Y] or [N] if this image of the three rectangles matches
 the first images of the three rectangles. There will be 72 trials in total.

 My question is how to properly organize the nested lists. Since we have
 three changing variables, the first image of rectangles, the nature
 scenery, and the second image of rectangles would there then be three
 individual nested lists (and three attributes on the original TrialList
 that these will be nested under)?

 I also need help in figuring out how attach a folder of these images (of the files) to
 the program. I believe that I have successfully included the individual image files under their respectable lists but I don't know how to reference the folders that these images are in, under the attributes on a List Object or on a Slide Object. 

[David McFarlane]

In order to have your attribute reference a folder containing a
stimulus, simply add the folder name as a preface, followed by a forward
slash. (Yes, Windows natively uses backward slashes as path separators,
but trust me, forward slashes solve some problems in this case.) Note
also that you may mix together multiple literal strings and attribute
references, as suits you, and you may do this in a List attribute as
well as right in the object properties. E.g., the following would work:

StimFolder/StimFile (literal path)
StimFolder/[StimFile] (literal path to folder, attribute reference
for file)
[StimFolder]/[StimFile] (attribute references for both folder & file,
weird)
[StimFolder]/StimFile (attribute reference for folder, literal for
file, weird)


For organizing the Lists, once again I will repeat my advice to think of
Lists as decks of playing cards -- if you think through how to do your
randomization with decks of playing cards, then you can simply adapt
that to E-Prime Lists. In this case, you could make two nested Lists
for each rectangle to assign its color and orientation, but note that
that organization might allow for undesired repeats or combinations. If
you instead think through all the combinations that you actually want to
allow, then you could make one List with a row for each combination and
use that. Note that your design allows for 9 color/orientation
possibilities for each rectangle, so for 3 rectangles that comes to 729
possible combinations. Is every one of those 729 combinations really
acceptable for your experiment, or do you want to put some limits on
that? And then you still have to think through trials in which the
first & second rectangle displays are the same or different.

-- David McFarlane

[Sommer Martin]

Thank you for explaining how to attach the folders.

As far as the rectangles and nested lists, repetition is fine. I have the combinations of color/orientation already fixed into set images (I created a total of 80 using a randomizer to choose color and orientation for each of the three rectangles in each image). The main practice of the task is for a slide object to show one file image of one of these images showing the rectangles. It will appear for 5 seconds and then a nature scene will appear for 15 seconds and then another slide object will show another file image of the rectangles - either different or similar to the previous one. For each trial of this task, the file image of the rectangles will be randomized, so a different one will appear in the first and second slide object, every trial. The nature scene that appears after the first slide object also changes each trial, so it has its own folder and multiple files. For this reason, I am unsure if I needed to organize a nested list for each. A nested list containing all of the image files to be used in the first slide object, then a nested list containing all of the image files for the nature scene, and then a nested list containing the rectangle images files again for the second slide object - in that order specifically. 

Within the initial list object that these nested lists will be organized under, is there a specific way that the attributes should be organized as well? Since the second slide object will  require the participant to answer [Y] or [N] (if the second rectangles image is the same as the first rectangles image shown in the first slide object) there has to be a correct response or answer attribute (I've named it Answer). Under this attribute for the first nested list and the nature scene, no answer is required, so can I leave those cells blank?

Thank you,

Sommer

[David McFarlane]

Had an exchange with Sommer about this outside of the Group, figured I
might as well post the result here for future reference.


We started by clarifying the specifications for Sommer's task ...

* You want to present 72 trials.
* On each trial you want to present one image with some rectangles
(let's assume you use a Slide object, and call it Rect1Slide), then a
nature scene (let's call it NatureSlide), then a tone (let's call it
ToneSound), and then another image with rectangles (let's call it
Rect2Slide).
* Half (36) of the trials will use the same rectangle image for
Rect1Slide & Rect2Slide, and half will use different images for
Rect1Slide & Rect2Slide.
* "Same" and "Different" trials may occur in any random order, with no
further constraints.
* You have a pool of 80 of the rectangle images.
* You would like to use each image at least once, in some randomized
order, with no further constraints.


Assuming no further constraints on the randomization I had some ideas.
Otherwise, I advised simply coming up with one suitable sequence and
then simply running that as a List running in Sequential order (as
advised in many other threads throughout the E-Prime Group). As it
turns out I neglected a specification to select images *with* (rather
than without) replacement -- I will address that at the end.

So then I set out in earnest with my ideas ...

As a starting exercise, let's see how we would do this with decks of
playing cards, and then implement that design in E-Prime.

Imagine you have a deck of 72 cards, with half (36) of them labeled
"Same", and half labeled "Different" -- let's call that TrialDeck.
Imagine you have another deck of 80 cards, each one with a different
image of rectangles -- let's call that RectDeck. You did not say
anything about the nature scenes, but I imagine that you have a number
of those to present in some random order, so we might as well also have
another deck for those -- let's call that NatureDeck, with some
arbitrary number of cards.

Start by shuffling each of these three card decks separately. On each
trial, draw one card from TrialDeck. Then draw one card from RectDeck.
Then of course one card from NatureDeck. Now comes the fun part -- if
the card drawn from TrialDeck says "Same", then just use the card that
you already drew from RectDeck for the second time; if the card from
TrialDeck says "Different", draw a second card from RectDeck.

Note that under the conditions given you will need to draw 36 + 2*36 =
108 rectangle cards throughout the session -- when you exhaust the deck
of 80 cards from RectDeck, simply reshuffle the deck and keep drawing
more cards.

This procedure guarantees that you will use every card from RectDeck at
least once as either the first or the second image on some trial, but
some cards might never serve as the first image (or as the second image)
on any trial; also, some rectangle cards will get used twice, and others
only once, and the same card may end up in a "Same" trial twice, etc.
It also has no control over runs of "Same" or "Different" trials. It
will however almost never use the same card for two trials in a row,
except possibly for the one trial after you reshuffle RectDeck. That's
the best I can do offhand.

So now let's implement this in E-Prime. Each Deck will become a List,
where TrialDeck becomes a main List and RectDeck & NatureDeck become
nested Lists. And it will use "colon syntax", which is a bit of an
advanced feature that you may learn about in Appendix C of the "E-Prime
2.0 User's Guide" (I also go over this in a lesson in my online E-Prime
2 course).

Here is how your structure might look now (I am using Slide objects,
although you might instead use simpler ImageDisplay objects):
- TrialList
--- RectList
--- NatureList
--- TrialProc
----- Rect1Slide
----- NatureSlide
----- ToneSound
----- Rect2Slide

TrialList has RectList and NatureList in each row of its "Nested"
column. It also has columns named "Rect1Image" and "Rect2Image" --
Rect1Slide will use [Rect1Image] to get its image file, and Rect2Slide
will use [Rect2Image] to get its image file. TrialList also has a
column for "NatureImage", which NatureSlide will use. If you like, you
may add another column to indicate Same vs. Different trials (call it
"TrialType"?) just for your own info, but we do not need that for the
program itself. Finally, we set TrialList to use Random order.

RectList (nested under TrialList) has a column that we will call
"RectImage". It has 80 rows, with a file name for RectImage in each
row, and we set this to use Random order.

NatureList (nested under TrialList) has a column that we will call
"NatureImage", with a file name for NatureImage in each row, and we set
this to use Random order.

Now back in TrialList, in the Rect1Image column, put "[RectImage:0]"
(without the quotation marks) in each row. In the Rect2Image column,
put "[RectImage:0]" for the same-RectImage trials, and "[RectImage:1]"
for the different-RectImage trials. Explanation -- [RectImage:0] means
use the top "card" that we drew from the RectList "deck", and
[RectImage:1] means draw one more "card" from the "deck", just like in
the playing card example that I gave above.

Also in TrialList, you may make 36 rows for the same-RectImage trials
and 36 rows for the different-RectImage trials; or, even easier, just
make two rows, one for same-RectImage trials and another for
different-RectImage trials, and give each of those rows a Weight of 36
-- E-Prime will treat this as a List of 72 rows and take care of the
shuffling for you.

Finally, Rect1Slide uses "[Rect1Image]" to gets its image file,
Rect2Slide uses "[Rect2Image]", and NatureSlide uses "[NatureImage]"
(we do not have to do anything special for NatureSlide because TrialList
implicitly picks up the NatureImage column from NatureList, but if it
makes you feel better you could add some sort of NatureImage column in
TrialList and then use that to reference the nested NatureList, etc.).


Finally, what about selecting images for the trials *with* (instead of
without) replacement? ...

Just to belabor the terminology a bit, sampling with replacement is like
rolling a die (or, drawing a card from a shuffled deck, then putting the
card back into the deck and reshuffling before drawing a card again),
while sampling without replacement is like simply drawing successive
cards from a shuffled deck of cards. The procedure outlined here
randomly samples the images *without* replacement, which makes things
easier; if you really need sampling *with* replacement then, in this
particular case, it makes things considerably harder. In fact, sampling
images with replacement pretty much conflicts with the requirement to
use each image at least once.

-- David McFarlane