Counters: something may be very, very wrong here


Author
Message
Blackadder
Blackadder
Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)
Group: Forum Members
Posts: 280, Visits: 147

Hi All,


consider the attached script. It's objective is very simple: Display the four letters "A", "B", "C", and "D" at once in consecutive order. I know you could do that much easier but this is for testing purposes only. The counters were originally set up as follows:


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

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

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

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



What I'd expect to happen is that the first counter selects element 1 (which would be "A" in the letters list), the second counter selects element 2 (letter "B") and so forth. The actual result is quite different, i.e. all letters are "A" in all trials, hence, the counters obviously ignore the "/ select" integer.


Then I tried to use "/ select = sequence(2,2,2,2)" for the second counter so that it reads


<counter COUNTER_text2>

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

/ select = sequence(2,2,2,2)

</counter>



To my understanding of counters, this should have the counter select its second element four times in a row. Again, something very different happens. The counter selects its first item on the first trial (corresponding to letter "A"), then the second item (letter "B") on the second trial and so forth, so that the first letter iterates sequentially from "A" to "D" across trials. It is as if I hadn't specified the "(2,2,2,2)".


Finally, I used "/ select = constant(3)" for the third counter which in my conception should yield the same behavior as "/ select = 3". Well, it does, but just as ill-mannered. Inquisit disregards the integer setting but always selects the first element (letter "A" again).


I can't believe that this is a faulty implementation. So I must be doing something wrong. Any hints?


Best wishes,
Malte


Attachments
NotOption.exp (637 views, 1.00 KB)
Dave
Dave
Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)
Group: Administrators
Posts: 10K, Visits: 51K

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


Dave
Dave
Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)
Group: Administrators
Posts: 10K, Visits: 51K

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



Blackadder
Blackadder
Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)
Group: Forum Members
Posts: 280, Visits: 147

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.



select attribute


<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



Blackadder
Blackadder
Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)
Group: Forum Members
Posts: 280, Visits: 147

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.


Dave
Dave
Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)
Group: Administrators
Posts: 10K, Visits: 51K

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


Blackadder
Blackadder
Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)
Group: Forum Members
Posts: 280, Visits: 147

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.


seandr
seandr
Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)Supreme Being (111K reputation)
Group: Administrators
Posts: 1.2K, Visits: 980

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



Blackadder
Blackadder
Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)Guru (18K reputation)
Group: Forum Members
Posts: 280, Visits: 147

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.


Dave
Dave
Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)Supreme Being (782K reputation)
Group: Administrators
Posts: 10K, Visits: 51K

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


GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Explore
Messages
Mentions
Search