Millisecond Forums

Just a quick reply at this point: AFAIK, the '/ select' attribute behaves differently for <counter> as opposed to stimulus elements (<text> et al.), because -- my best guess -- <counter> elements are primarily intended for item selection. For example, having <counter a> select its items based on a value returned from <counter b> won't really work either (i.e. doesn't work at all or leads to unintended results). In my view, <counter>s currently are the end of Inquisit's selection hierarchy. Whether there are any bugs involved in what you've been observing or whether what you're seeing is 'by design' is beyond me. However, I really don't 'get' what the code you posted is supposed to achieve -- I can't see why one would ever try to implement something like this (no offense intended).

~Dave

Still not sure whether we're seeing bugs at work here, but I'll add a few further remarks. Basically, you're creating ambiguities in the <counter> definitions you posted. For example, '/ select = sequence(2,2,2,2)' is nothing but a shorthand notation.

<counter mycounter>
/ items = (2,2,2,2)
/ select = sequence
</counter>

is equivalent to

<counter mycounter>
/ select = sequence(2,2,2,2)
</counter>

Now, if you instead define

<counter mycounter>
/ items = (1,2,3,4)
/ select = sequence(2,2,2,2)
</counter>

you've essentially created an ambiguity. Should Inquisit select (1,2,3,4) in sequence or rather (2,2,2,2)? As you've observed, the expressions parser simply opts to ignore (2,2,2,2) and go for sequential selection of (1,2,3,4) as in

<counter mycounter>

/ items = (1,2,3,4)

/ select = sequence

</counter>

I'd prefer the parser to throw an error in case of such ambiguities. However, I'm not sure about the '/ select = integer' issue you observed. I've built similar counter-logics in the past a la

<counter mycounter>

/ items = (1,2,3,4)

/ select = values.number

</counter>

where values.number is an integer value dynamically determined by the script's logic. These have been working fine (check out this script for a working example: http://www.millisecond.com/download/samples/v3/KarpickeRoediger2008/default.aspx).

So, this one really appears to be a bug.

~Dave

Sorry, Dave, I'm completely not with you on this one. To my understanding, which derives only from the help examples on counters, the following should hold:

/ items = (11, 12, 13, 14)

are the contents of the counter, i.e. the values one of which will be returned when the counter is accessed. Let's call them "elements" for now.

Very different from that

/ select = sequence(1, 2, 3, 4)

gives indices to the elements, meaning that if "1" is selected from the sequence, the element "11" ist returned. I've always conceived the numbers in a sequence as an array of indices to another array of elements, with the latter being the elements of the counter. To me, the second example from the help is quite elucidating in this regard.

<text presidents>
/ items = ("George Washington",
"John Adams", "Thomas Jefferson")
/ select = sequence(3, 2,
1)
</text>

The sequence defines that the president names will be returned in inverse order. No ambiguity emerges whether Inquisit shall return the numbers 3, 2, 1 or the president names because 3, 2, and 1 are always just indices to the elements of the items list. Why should this suddenly change when the items list consists of numbers which incidently also appear in the sequence? If it did change, I'll file that as a bug because elements and indices to elements are two very different things.

The same holds for "/ select = 4". It should be clear that you don't tell Inquisit to select the number 4 as the next return value but the 4th element from the items list.

Oh, and for the real-world value of my code. Suppose you wanted to implement specific presentation sequences but on different classes of items. You could write

<counter A>
/ items = ("snappy", "hairy", "cold")
/ select = (1, 1, 1, 2, 2, 2, 3, 3, 3, 1, 2, 3, 2, 1)
</counter>

<counter B>

/ items = ("velvet", "silk", "hot")

/ select = (1, 1, 1, 2, 2, 2, 3, 3, 3, 1, 2, 3, 2, 1)

</counter>

<counter C>
/ items = ("chicken", "horse", "dog")


/ select = (1, 1, 1, 2, 2, 2, 3, 3, 3, 1, 2, 3, 2, 1)


</counter>

It saves you a lot of time when you don't have to convert each of the item lists into the desired sequence but just write down the element index sequence once and copy it to all counters. And, yes, I know there is another very obvious and similarly easy way to do such a thing but at least this should work, shouldn't it?

Bye, Malte

Granted, the help example for the "select" property
involves a text stimulus but it is referred to from the "counter"
help page, so I'd expect select to operate identically in both
contexts.

You need not be sorry about disagreeing with me. That's perfectly fine. Actually, I don't even think we have a disagreement here... Also note that I'm not advocating the current <counter> behavior as being "ideal" -- I'm just stating my observations (which for the most part are accurate). As I already said, whether the described aspects (different behavior of  /select for <text> vs <counter> elements, etc.) are due to bugs, implementation inconsistencies or intended is beyond me. I guess I've just learned to live with the way it is (which is not necessarily a good thing)...

~Dave

In a nutshell: as of today, one may completely forget

a) the "/ select = integer"

b) the sequence list in "/ select = sequence"

c) the number in "/ select = constant"

when dealing with counters because Inquisit is indecisive about the interpretation of the number(s) provided in any of these cases (are they indices, are they return values, or are they just to be ignored?).

Does it sound sensible when I say that you made something very unclear by perfectly clarifying it?

Malte.

Hi Malte,

I agree the behavior of counters are confusing in this regard. The original syntax assumed they would always be used as indexes into stimulus items sets rather than position their own pool of items to select from. Thus, the item pool and indexes are somewhat conflated.

As for the examples you posted, I agree that they are broken. However, the following syntax should accomplish exactly the same thing:

<counter COUNTER_text1>
/ select = 1
</counter>

<counter COUNTER_text2>
/ select = 2   
</counter>

<counter COUNTER_text3>
/ select = 3
</counter>

<counter COUNTER_text4>
/ select = 4
</counter>

This seems acceptable to me as a workaround for now, because I'm not sure how common or necessary it is to specify a big item pool if you plan to select the same item each time. Still, I agree this is confusing and the indexes and values clearly need to be separated out more clearly in the counter object.

-Sean

Dear Sean,

thanks for responding! The example was a stripped down version of what I intended to do, I like to keep things as simple as possible in the demo scripts I post here. To be honest, the actual script was conceived as nothing more than a test version, too. Yesterday, I stumbled upon the "/ not" property of counters and - contrary to the help - found that you can pass a list to it.

That seemed like digging up gold since it, if functional, would have solved a problem I was struggling with. I have four sets of stimuli, each of which contributes one element to every trial. The stimulus pairing scheme requires that in any given trial, each stimulus chooses an element with a unique index. Hence, when stimulus 1 drew item element 4, no other stimulus must draw element 4 from its associated item list in that particular trial.

So I thought, maybe this will work:

<counter COUNTER_text1>
/ items = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
/ select = noreplace
/ not = (COUNTER_text2,COUNTER_text3,COUNTER_text4)
</counter>

<counter COUNTER_text2>
/ items = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
/ select = noreplace
/ not = (COUNTER_text1,COUNTER_text3,COUNTER_text4)
</counter>

<counter COUNTER_text3>
/ items = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
/ select = noreplace
/ not = (COUNTER_text1,COUNTER_text2,COUNTER_text4)
</counter>

<counter COUNTER_text4>
/ items = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
/ select = noreplace
/ not = (COUNTER_text1,COUNTER_text2,COUNTER_text3)
</counter>

Of course it doesn't, which is why I tried to strip down the counter logic until I arrived at some configuration where "/ not" would actually evaluate multiple counters simultaneously. After some serious downstripping I arrived at the above script which had me understand that my conception of how counters work was far from correct.

Best wishes,
  Malte.

Malte,

multiple /not attributes will get you what you're looking for. If you download the SOPT sample from the Task Library and set all the contained counter's selectionmode to 'noreplace' you can even see it in action (the script's comments have more info on this).

~Dave