Hi I am trying to design a simple classification task in which participants switch between classifying a number (odd/even) and a letter (vowel/consonant).
Up till now I randomize the select of the classification (whether letter or number), however, I now want to control how many trials are switch trials (i.e., letter/number or number/letter) and how many are non-switch (letter/letter and number/number).
I would appreciate any help on this.
Till now I have no code and all have been designed using builder. I am attaching a screenshot of this.
Would you be happy for me to use your experiment as the basis of a public demo for this?
In order to balance both switch/same trials and letter/number trials I’d use a variation on my independent randomisation demo but with two separate switch balancing lists. In the spreadsheet I’d put a letter and a number in the same row so that either of the two can be selected as appropriate.
I’m currently marking, but I can easily find enough time next week.
I’m also just now implementing a task-switching experiment and mostly rely on Builder.
Usually, it is dfficult to generate constrained randomization online, since you may run into a dead end (the next trial must be type X, but all trials of type X have already been used up). Therefore, I prepare csv files in R (quite brute force, actuially, simply generating an order and then testing whether the number of same and switch trials is the same and only keeping those).
Then I restrict my participant codes to be pp01…pp99 (actually probably pp40) and then use the number to read in a specific file in a code component in Builder, as below
You may be interested in my new Randomisation without repetition demo. I deal with the dead end issue by adding additional trials if the experiment is about to get stuck. It’s not a perfect solution, but I wanted to present an alterative to the approach of preloading the trials and reshuffling until the order passes the criteria.
This demo randomises switch and non-switch trials in a classification task. The conditions are preloaded using a code component and allocated to two lists so that switch and non-switch trials can be balanced. The first trial type is random and the final one is allocated based on the remaining condition available.