Choosing task variables randomly without replacement

Hi Chris,

We talked about all this on the phone, and we agreed I’d write out exactly what I want to do.

Description
My goal is to choose some task variable randomly without replacement across a set of trials, with adjustable weighting. Let’s say I’m changing stimulus direction, and I want to use 4 new directions, some easy (big change, say 65 degrees) and some hard (e.g. 5 degree change).
Over a block of 32 trials, if I space these evenly that would be 8 of each. But often we want, more of the easy ones, e.g. 12, and fewer of the hard ones, e.g. 4. So my weighting would be [12 12 4 4], which sums to 32.
And my direction change values in degrees would be [65 45 25 5].

To achieve this now, I use a selection variable with 4 values.
I have 4 “odds” variables:
odds1, odds2, odds3, odds4.
and 4 “values” variables.
direction1, direction2, direction3, direction4.
I also need a variable to track how many stimuli have been chosen
nAccepted

At the beginning of the block, I reset the selection variable. After each display I “accept_selection” and “next_selection” and increment nAccepted, then check if it is the same as the sum over all odds. If so I reset_selections and set nAccepted to 0.

I use a long series of “if” statements to check if the selection variable is between each odds value and if so set the direction.

This is fine for now but it’s unwieldy. I’d love to solve all the issues below but the bottom ‘big’ issue is our priority.

Possible easy improvements

  • selection variable method which gives nAccepted to remove bookkeeping
  • Better method than sequential “if” to map selection var → direction
    (e.g. array variable? Do in python?)

Biggest limitations - that require architecture changes

  • Both “sampling” and “values” of the selection variable can only be changed at parse time. This has recently bitten us here; for some experiments we want sampling=sequential_ascending and for others random_without_replacement. And we often need to change the number of values; if we only want to use 3 directions we may want the sum to be 30, an even multiple.

Hi Mark,

Looking back at this (now 2+ years old) issue, am I correct to think that we’ve addressed your needs with subsequent feature additions (i.e. the numAccepted function, better support for list variables, support for embedded Python)? Are there additional enhancements that you think would be useful for this type of task?

Thanks,
Chris

Yes, that’s right, we have now solved this. Thank you!