Randomization anomalies using elements


Author
Message
AKrishna
AKrishna
Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)
Group: Forum Members
Posts: 93, Visits: 279
Dear all,

I've run into an issue that I can't for the life of me figure out. I have a fairly complicated Inquisit script that runs an approach-avoidance manikin task in trial pairs, where the condition assignment depends on 8 two-level factors (i.e., 256 conditions). In addition, the script needs to do a lot of other stuff (e.g., randomly select color sets for targets, measure slow responses and incorrect responses and assign a reward based on quotas, include a practice block with a separate condition list, repeat incorrect trials until the participant gets them right in the practice block, but only once in the main task etc.), which has made it difficult to debug this problem.

The observed behavior is that when I run my script file using the test monkey, the generated test data will occasionally have irregular distributions of conditions. As an example, I've uploaded a data file I generated using a simplified version of the experiment with 128 conditions (also attached as a script). First, one should note that the data file contains data from the practice block as well (all blocks where BlockCounter < 1). It's also important to note that there are more than the expected 256 trials (128 trial pairs, 1 per condition = 256 trials) in the data file, as this script also includes code that causes error trials to repeat once at the end of the block. Thus, the expected behavior of the script is to run 128 trial pairs in a block, drawing from the Conditions <list> in the script (which has 128 elements), and then to continue the block with single repetitions of conditions that were responded to incorrectly (captured in the ConditionsCollectedErrors <list> at the end of the AAT trial). This should mean that in the first 256 trials, the conditions (indexed in values.SequenceType) should each occur precisely once.

As can be seen in the data file, this is not the case. Subject number 5 sees one sequence twice in blocks 2, 3, and 4 (not always the same sequence). The SequenceType for the last trial pair among the first 128 (i.e. trials 255+256) in these blocks occur twice in that set of 128 trial pairs instead of once, with another SequenceType presumably conversely missing in the set. It's almost as though list.Conditions is selected from one too many times and the first selection is being dropped somehow. Unfortunately, as can also be seen in the dataset, this does not happen predictably - of 15 monkeys in this dataset, only 1 shows the issue.

I've tried reducing the problem to a simpler script, but the bug doesn't appear to occur if I limit list.Conditions to the first 8, 16, 32, or 64 elements (admittedly I only tested each of these with 15 monkeys, so I might just have failed to detect it). I'm relatively sure that the problem lies somewhere with my additional bells and whistles (intuitively, I particularly suspect the code that repeats the error trials), but I've gone over it multiple times and can't find the issue.

I would appreciate any help or tips as to what might be going on!

I couldn't upload the data file to the forum because of its size (8mb), so here it is on Sync:
https://ln5.sync.com/dl/4034d7ec0/8w24j3cf-nmxnc22y-viay2gpq-v92pchge

Also, here's the R code I use to check whether the conditions are being assigned properly (requires tidyverse):

library(tidyverse)

rawdatasingles <- read_tsv("X:/ALLG2/AAT SR-Binding/Experiment 6/Programming/data/Simplified 128 conditions_raw.iqdat")

# getting prime and probes into one row

rawdata <- rawdatasingles %>% mutate(TrialCounter = if_else(TrialCounter %% 2 == 0,TrialCounter-1,TrialCounter)) %>%
mutate(BlockCounter = case_when(BlockCounter == 0 ~ PracticeBlocksThatWereCompleted * -1,
TRUE ~ BlockCounter)) %>%
pivot_wider(id_cols = c(subject,BlockCounter, TrialCounter,DistracterCondition,GoalResponseCondition,
MotorResponseCondition,RelevantStimulusCondition), names_from = CurrentTrialTypeInSequence,
values_from = c(DesiredResponse,ManikinPosition,TargetStimColor,
AATTargetWord,correct,response,SequenceType))

# checking whether conditions are evenly assigned

rawdata %>%
filter(BlockCounter > 0 & TrialCounter <= 256) %>%
count(subject,BlockCounter,DistracterCondition,GoalResponseCondition,MotorResponseCondition,RelevantStimulusCondition,
DesiredResponse_Prime,ManikinPosition_Prime,TargetStimColor_Prime,AATTargetWord_Prime) %>%
arrange(desc(n)) %>%
group_by(subject,BlockCounter,n) %>%
count(GoalResponseCondition) %>% # vary the condition variable in this line to see distributions across other condition combinations
view

rawdata %>%
filter(BlockCounter > 0 & TrialCounter <= 256) %>%
count(subject,BlockCounter,SequenceType_Prime) %>%
arrange(desc(n)) %>%
group_by(subject,BlockCounter,n) %>%
view


Attachments
Manikin SRBR1 v0.9 simplified.iqx (111 views, 60.00 KB)
Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
AKrishna - 1/27/2022
Dear all,

I've run into an issue that I can't for the life of me figure out. I have a fairly complicated Inquisit script that runs an approach-avoidance manikin task in trial pairs, where the condition assignment depends on 8 two-level factors (i.e., 256 conditions). In addition, the script needs to do a lot of other stuff (e.g., randomly select color sets for targets, measure slow responses and incorrect responses and assign a reward based on quotas, include a practice block with a separate condition list, repeat incorrect trials until the participant gets them right in the practice block, but only once in the main task etc.), which has made it difficult to debug this problem.

The observed behavior is that when I run my script file using the test monkey, the generated test data will occasionally have irregular distributions of conditions. As an example, I've uploaded a data file I generated using a simplified version of the experiment with 128 conditions (also attached as a script). First, one should note that the data file contains data from the practice block as well (all blocks where BlockCounter < 1). It's also important to note that there are more than the expected 256 trials (128 trial pairs, 1 per condition = 256 trials) in the data file, as this script also includes code that causes error trials to repeat once at the end of the block. Thus, the expected behavior of the script is to run 128 trial pairs in a block, drawing from the Conditions <list> in the script (which has 128 elements), and then to continue the block with single repetitions of conditions that were responded to incorrectly (captured in the ConditionsCollectedErrors <list> at the end of the AAT trial). This should mean that in the first 256 trials, the conditions (indexed in values.SequenceType) should each occur precisely once.

As can be seen in the data file, this is not the case. Subject number 5 sees one sequence twice in blocks 2, 3, and 4 (not always the same sequence). The SequenceType for the last trial pair among the first 128 (i.e. trials 255+256) in these blocks occur twice in that set of 128 trial pairs instead of once, with another SequenceType presumably conversely missing in the set. It's almost as though list.Conditions is selected from one too many times and the first selection is being dropped somehow. Unfortunately, as can also be seen in the dataset, this does not happen predictably - of 15 monkeys in this dataset, only 1 shows the issue.

I've tried reducing the problem to a simpler script, but the bug doesn't appear to occur if I limit list.Conditions to the first 8, 16, 32, or 64 elements (admittedly I only tested each of these with 15 monkeys, so I might just have failed to detect it). I'm relatively sure that the problem lies somewhere with my additional bells and whistles (intuitively, I particularly suspect the code that repeats the error trials), but I've gone over it multiple times and can't find the issue.

I would appreciate any help or tips as to what might be going on!

I couldn't upload the data file to the forum because of its size (8mb), so here it is on Sync:
https://ln5.sync.com/dl/4034d7ec0/8w24j3cf-nmxnc22y-viay2gpq-v92pchge

Also, here's the R code I use to check whether the conditions are being assigned properly (requires tidyverse):

library(tidyverse)

rawdatasingles <- read_tsv("X:/ALLG2/AAT SR-Binding/Experiment 6/Programming/data/Simplified 128 conditions_raw.iqdat")

# getting prime and probes into one row

rawdata <- rawdatasingles %>% mutate(TrialCounter = if_else(TrialCounter %% 2 == 0,TrialCounter-1,TrialCounter)) %>%
mutate(BlockCounter = case_when(BlockCounter == 0 ~ PracticeBlocksThatWereCompleted * -1,
TRUE ~ BlockCounter)) %>%
pivot_wider(id_cols = c(subject,BlockCounter, TrialCounter,DistracterCondition,GoalResponseCondition,
MotorResponseCondition,RelevantStimulusCondition), names_from = CurrentTrialTypeInSequence,
values_from = c(DesiredResponse,ManikinPosition,TargetStimColor,
AATTargetWord,correct,response,SequenceType))

# checking whether conditions are evenly assigned

rawdata %>%
filter(BlockCounter > 0 & TrialCounter <= 256) %>%
count(subject,BlockCounter,DistracterCondition,GoalResponseCondition,MotorResponseCondition,RelevantStimulusCondition,
DesiredResponse_Prime,ManikinPosition_Prime,TargetStimColor_Prime,AATTargetWord_Prime) %>%
arrange(desc(n)) %>%
group_by(subject,BlockCounter,n) %>%
count(GoalResponseCondition) %>% # vary the condition variable in this line to see distributions across other condition combinations
view

rawdata %>%
filter(BlockCounter > 0 & TrialCounter <= 256) %>%
count(subject,BlockCounter,SequenceType_Prime) %>%
arrange(desc(n)) %>%
group_by(subject,BlockCounter,n) %>%
view


(1) Please provide a more comprehensively commented version of the script. Since, as you say and I agree, it is complex and has a lot of moving parts, all key components should have clear explanations re. what they're intended to do and why they're set up the way they are.
(2) The script relies on external files to run. Provide those files.
AKrishna
AKrishna
Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)
Group: Forum Members
Posts: 93, Visits: 279
Sorry. Hope this is better!

Attachments
maennchen.png (102 views, 3.00 KB)
Manikin SRBR1 v0.9 simplified.iqx (107 views, 69.00 KB)
Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
AKrishna - 1/27/2022
Sorry. Hope this is better!

Not having any luck reproducing this across ~20 monkey runs so far. Quick question: Did you, at any point during your test runs, invoke the built-in debugging window (CTRL+D)? That can cause extraneous samples on a list when its properties are queried.
AKrishna
AKrishna
Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)
Group: Forum Members
Posts: 93, Visits: 279
Dave - 1/27/2022
AKrishna - 1/27/2022
Sorry. Hope this is better!

Not having any luck reproducing this across ~20 monkey runs so far. Quick question: Did you, at any point during your test runs, invoke the built-in debugging window (CTRL+D)? That can cause extraneous samples on a list when its properties are queried.

....Yes, yes I did. That could very well be the problem. I'll run as many monkeys as I can overnight without debug mode today. If I can't reproduce it, then you probably found the problem.

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
AKrishna - 1/27/2022
Dave - 1/27/2022
AKrishna - 1/27/2022
Sorry. Hope this is better!

Not having any luck reproducing this across ~20 monkey runs so far. Quick question: Did you, at any point during your test runs, invoke the built-in debugging window (CTRL+D)? That can cause extraneous samples on a list when its properties are queried.

....Yes, yes I did. That could very well be the problem. I'll run as many monkeys as I can overnight without debug mode today. If I can't reproduce it, then you probably found the problem.

I'm about 99% certain that was the problem. For what it's worth, attached a script version with some additional variables useful for debugging plus another set of 15 monkey runs using this script revision. (These are additional to the about 30 or so I did before.)

The logged selectedcount and unselectedcount properties help keeping track of how many samples are taken from the given list and when. sequencetype_num is a numerical representation of sequencetype, which I find easier to work with. sampled_from records from which list a given trial sampled (PC = practice conditions; PCCE = practice conditions collected errors; C = conditions; CCE = conditions collected errors).

Oh, and just so we're on the same page: All these runs were conducted using the current Inquisit 6 release (6.5.2).
Attachments
Edited 2 Years Ago by Dave
AKrishna
AKrishna
Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)Distinguished Member (3.2K reputation)
Group: Forum Members
Posts: 93, Visits: 279
You're a marvel, Dave. 30 monkey runs last night produced no problems - it was the debug mode. I'm amazed that you caught that so quickly - seems like the kind of error that would take a lot of work to even come up with normally. Well done!

And thanks for your testing efforts, as well

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
AKrishna - 1/28/2022
You're a marvel, Dave. 30 monkey runs last night produced no problems - it was the debug mode. I'm amazed that you caught that so quickly - seems like the kind of error that would take a lot of work to even come up with normally. Well done!

And thanks for your testing efforts, as well

> 30 monkey runs last night produced no problems - it was the debug mode.

That's great to hear! Thanks for letting me know.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Explore
Messages
Mentions
Search