PennController for IBEX › Forums › Support › Pseudo-randomising stimulus presentation
- This topic has 10 replies, 4 voices, and was last updated 2 years, 5 months ago by
Jeremy.
-
AuthorPosts
-
May 14, 2020 at 5:40 am #5245
zoe_f
ParticipantHi there!
I have a question about pseudo-randomising the order of stimulus presentation. (I looked at all the randomising threads in the support forum and couldn’t find anything about this particular issue, but do let me know if this has already been answered and I’ll look there).
I want to do a classic pseudo-randomised order of stimulus presentation in my experiment. I have two conditions, 1 and 2, with stimuli counterbalanced across these conditions by means of two lists (i.e., everyone sees all stimuli in either one of the two conditions). Each stimulus is in one of 3 categories, A, B, and C, with categories represented equally in the two conditions. I want to randomise order presentation of each of the two lists, but without the same condition and category appearing more than let’s say twice in a row, i.e., no occurrences of 2A, 2A, 2A in stimulus presentation.
Is there any way to specify pseudo-randomisation automatically by making reference to the condition/category columns in the data table? Or do I have to manually order my stimuli within the .csv file and scrap the randomise() sequence function altogether?
With many thanks,
Zoë
May 14, 2020 at 6:20 am #5246zoe_f
ParticipantP.S. I am aware of the rshuffle command, which could potentially be useful for this problem (certainly easier than manually deciding an order for stimulus presentation!). However, as far as I understand rshuffle, you have to specify a set order for the categories you’re drawing from, so in my case I’d have to say present items in order e.g., B-A-C (wherein items from within each of those three groups are randomly selected). So category is not really randomly presented, but items are.
May 14, 2020 at 10:46 am #5250Jeremy
KeymasterHi Zoë,
I answered a similar question on the original Ibex forums: https://groups.google.com/d/msg/ibexexperiments/1987FoZKo6k/XAw_XoX3AQAJ
You should upload a .js file to the Controllers folder that contains the following code:
function RandomizeNoMoreThan(predicate,n) { this.args = [predicate]; this.run = function(arrays) { let moreThanN = true; let order; while (moreThanN){ order = randomize(predicate).run(arrays); moreThanN = false; let previousType = ""; let current_n = 0; for (let i = 0; i < order.length; i++){ let currentType = order[i][0].type; if (currentType != previousType){ current_n = 1; previousType = currentType; } else{ current_n++; if (current_n > n){ moreThanN = true; break; } } } } return order; }; } function randomizeNoMoreThan(predicate, n) { return new RandomizeNoMoreThan(predicate,n); }
Then in your main script you can do this:
Sequence("intro", randomizeNoMoreThan(anyOf("1A", "1B", "1C", "2A", "2B", "2C"),2), "exit")
Be very careful with it though, as it will freeze in an infinite loop if you don’t have enough items with each label to consistently break series of N items sharing the same label. For example, if you have 90 “1A” items but only a total of 10 items across the other labels, there is no way of avoiding series of more-than-two “1A” items and so your experiment would end up crashing.
Jeremy
May 14, 2020 at 1:25 pm #5256zoe_f
ParticipantGreat, thank you so much for this! That’s very helpful, I’ll upload that to my script folder. I’ve now had a look at Nora’s question at well in the original Ibex platform.
Thanks also for flagging up this potential problem. In theory it shouldn’t be an issue as I have equal numbers of stimuli distributed across all group/condition combinations (i.e., 12 1As, 12 1Bs, etc.), but could it possibly happen that the function accidentally doesn’t use a particularly category at the beginning of the Block/trial set, and is therefore ‘forced’ to use them at the end and crash itself? While I’ll of course test the experiment many times before publishing it, this seems like the kind of issue/error which might only be exposed at random, or across a very large number of iterations.
Thank you so much!
May 14, 2020 at 1:31 pm #5257Jeremy
Keymastercould it possibly happen that the function accidentally doesn’t use a particularly category at the beginning of the Block/trial set, and is therefore ‘forced’ to use them at the end and crash itself?
When this happens, the function simply generates a new order. This is precisely why it could get stuck into an infinite loop: its a brute-force method, it keeps generating random orders until one matches the specified pattern. As long as your items make it possible to generate a matching pattern, the function will eventually return one.
Jeremy
May 15, 2020 at 6:14 am #5259zoe_f
ParticipantOh I see, it only starts the experiment once it has generated a fullly specified order which follows the rules (I had thought the Sequence function made up the order trial-by-trial during stimulus presentation, but of course it’s much smarter than that). This is excellent. Thank you!
July 19, 2020 at 2:45 pm #5803karmacoma
ParticipantHi Jeremy,
Do the labels (e.g. “1A”,”1B”,”1C”) refer to the item names in the csv file? Or do they refer to specific trial names? Thank you.
July 19, 2020 at 4:31 pm #5804karmacoma
ParticipantOh never mind I figured it out!
April 2, 2022 at 5:49 pm #8001suleymanyaman
ParticipantHi Jeremy,
I found this old post when searching through pcibex. You said that unbalanced number of items across the conditions could pose a problem since it will freeze the experiment. My experimental/filler item ration is 1:2, so would this also cause an issue in such a case? Or would it be OK since I will only need to pass the conditions from CSV file as arguments?
April 2, 2022 at 5:54 pm #8002suleymanyaman
Participant*ratio, sorry for the typo!
April 3, 2022 at 10:05 pm #8004Jeremy
KeymasterHi,
I said it would freeze the experiment “if you don’t have enough items with each label to consistently break series of N items sharing the same label.” If your ratio is 1 experimental item for 2 fillers, the only constraint you have is you cannot go lower than series of 2 same-labeled trials, because then you would be forcing each filler to always be followed by at least one experimental item, but you would run out of experimental items after separating the first half of your filler items. Allowing series of 2 is fine though, because then you have enough items with both labels
Jeremy
-
AuthorPosts
- You must be logged in to reply to this topic.