Millisecond Forums

Hi Iwona,

that's a very easy one. Just declare your stimuli, trials, and block as outlined down below. The key idea is to split your trials into two possible orders, i.e., prime-target and target-prime. Inquisit will care for the correct balancing so that all possible combinations will be realized, if the block size (multiples of 256 in your case) fits.

Regards, Malte


<picture pic_PRIMES>
...
</picture>

<picture pic_POSTARGETS>


...


</picture>

<picture pic_NEGTARGETS>


...


</picture>


<trial trial_POS_ORDER1>

/ stimulusframes = [1 = PRIMES, 21 = POSTARGETS]

</trial>

<trial trial_POS_ORDER2>

/ stimulusframes = [1 = POSTARGETS, 21 = PRIMES]

</trial>

<trial trial_NEG_ORDER1>

/ stimulusframes = [1 = PRIMES, 21 = NEGTARGETS]

</trial>

<trial trial_NEG_ORDER2>

/ stimulusframes = [1 = NEGTARGETS, 21 = PRIMES]

</trial>


<block block_MAIN>
/ trials = [1 - 256 = noreplace(trial_POS_ORDER1, trial_POS_ORDER2, trial_NEG_ORDER1, trial_NEG_ORDER1]
</block>

Actually, I understand the question a bit differently. From what I gather, the goal is to ensure that each possible prime-target combination is realized (a combinatorial problem). So, prime #1 needs to precede each of the 8 positive targets and each of the 8 negative targets *exactly* once. Same goes for prime #2 and so on to prime # 16. This will yield 128 positive trials (16 primes * 8 positive targets) and 128 negative trials (16 primes * 8 negative targets). I think, the right way to pull this off is to use a set of 2(positive, negative) * 2(prime, target) counters for the item selection that contain the "hardcoded" permutations. For example, <counter counter_primes_positive> would list the item numbers for your 16 primes (8 times each because each prime needs to be combined with each positive target).

<counter counter_primes_positive>
/ select = noreplace
/ items = (
1,1,1,1,1,1,1,1,
2,2,2,2,2,2,2,2,
3,3,3,3,3,3,3,3,
4,4,4,4,4,4,4,4,
5,5,5,5,5,5,5,5,
6,6,6,6,6,6,6,6,
7,7,7,7,7,7,7,7,
8,8,8,8,8,8,8,8,
9,9,9,9,9,9,9,9,
10,10,10,10,10,10,10,10,
11,11,11,11,11,11,11,11,
12,12,12,12,12,12,12,12,
13,13,13,13,13,13,13,13,
14,14,14,14,14,14,14,14,
15,15,15,15,15,15,15,15,
16,16,16,16,16,16,16,16)
</counter>

The corresponding target counter would list the item numbers for the positive targets like this:

<counter counter_targets_positive>
/ select = current(counter_primes_positive)
/ items = (
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8,
1,2,3,4,5,6,7,8)
</counter>

With these two counters, each possible prime-target combination will be shown in your 128 positive trials. The same thing, of course, also needs to be done for the 128 negative trials. I've attached a small template script containing all necessary elements for further reference. My testing data show that the script performs as desired (each prime-target combination is run once in random order). Actually, this was fun!

Best,
~Dave

Dave is right, I again overestimated Inquisit's balancing capabilities. I remember talking to Sean about this issue quite often.

The awkward thing with the random drawing modes offered by Inquisit is that the "noreplace" selectionmode is implemented in a very specific way. I strongly believe that, when two stimuli are defined as "noreplace", then pairing these stimuli within a trial ought result in frequencies of pairings that are either a) equal or b) only differ by 1, and never by more than 1. Case a) would hold if the trialcount is a multiple of the number of possible combinations of the two stimuli, case b) in every other instance.

However, this is, for some reason I have not yet understood, different to what Inquisit actually does. In the example code provided by me, some of the combinations of primes and targets may never be realized, regardless of the trialcount, while others may be presented 3 times or more. This is not what I'd expect "noreplace" to do and brings the question to mind, what exactly noreplace would be good for then?

Malte.

Malte,

By default, each stimulus set has its own random selector that is independent of the selectors for other stimuli. I think this is a sensible default. It certainly keeps things simple from an implementation standpoint.

To handle the case where you want every combination of two (or more) stimuli presented exactly once, I've been thinking of adding a new option to the /select command (perhaps called "factorial"  - other suggestions are welcome).

For example, to present every combination of a prime and target, you would use the following syntax:

<text prime>
/ items = primes
/ select = factorial(target)
</text>  

<text target>
/ items = targets
/ select = factorial(prime)
</text>  

Any feedback on this idea is welcome.

-Sean

Me likes!

Me too.

We were facing the same problem with our lab software written by me (psychophysics stuff with all the generation routines for mathematically defined stimuli). The solution Sean is proposing is exactly what I implemented after hours of thinking and testing, namely to allow users to define the independence/interdependence of multiple stimulus groups with respect to the sampling mode.

However, the solution required some additional error checking, or sanity checks, if you will. The combinatorics, particularly when chains of factorial stimulus groups are allowed, get out of hand pretty fast. Users WILL set up designs with ridiculously large numbers of possible combinations. What I ended up with at last was a hybrid factorial mode. If the number of possible combinations is lower than the specified trial count, all combinations are realized, if not, no pairwise difference of frequencies for specific combinations is allowed to become larger than 1.

Malte

Hi,

It works exactly like it should work :)

Thanks a lot!

Greetings

Iwona