Millisecond Forums

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

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.

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

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

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