Millisecond Forums

Thanks for the test cases, Dave, they definitely clarify things. I've run through a few of them, and I think the problem is more of a design issue than a bug per se.

The issue is that counters select values on the fly, which might lead to situations where it is impossible for a counter to satisfy both the NOREPLACE and NOT constraints. Consider the following example:

       a    b   c    d
t1   2    4    1    3
t2   3    1    2    4
t3   1    2    4    2
t4   4    3    3    1

Things go along nicely until it is time for d to select a value on t3. D has two items, 1 and 2, left in the pool. However, both of those have already been selected on t3 by a and b, so what should it do? Currently, the NOREPLACE rule is given precedent, so it selects from the remaining pool. However, even if NOT were given precedent and it selected 3, you still don't get a nice neat factorial because d already selected 3 on t1.

I'm fairly certain there is no way to always satisfy both NOT and NOREPLACE constraints with "on the fly" selection. Depending on the size of the matrix, there will be some probability that a counter will be painted into a corner. Perhaps we could preselect various matrices until we find one that works, but I'm not convinced that will work either since we have no way of knowing exactly a) how many trials there will be, and b) on which of the trials a given counter will be used, because trials and selections may be inserted or skipped based on data that isn't known at the start of an experiment. 

I think the solution must allow you to define selection matrices. This could take the form of a multi-dimensional counter such as the following:

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

where subitems can be referenced with an index:

<text one>
/ items = ("a" "b" "c" "d")
/ select = counter.all.selectedvalue.1
</text>

<text two>
/ items = ("a" "b" "c" "d")
/ select = counter.all.selectedvalue.2
</text>

Or it could be accomplished by a new /select option:

<counter group>
/ items = (1,2,3,4)
/ select = noreplace
[...]
</counter>

<counter subgroup>
/ items = (1,2,3,4)
/ select = factorial(group)
</counter>

<text one>
/ items = ("a" "b" "c" "d")
/ select = counter.subgroup.selectedvalue.1
</text>

<text two>
/ items = ("a" "b" "c" "d")
/ select = counter.subgroup.selectedvalue.2
</text>

I think the first option is more flexible, explicit, and intelligible, although things get a little cumbersome as the matrix grows (a 20x20 matrix would involve a lot of typing). Possibly there are some better approaches than either of these - ideas are certainly welcome.

As a historical note, support for factorial selection has been on the feature list since it was first requested way way back in version 1.

-Sean

Well, for a start, I'd suggest

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

which would be a tad less error-prone and, to me, appears more readable then the matrix based version. Plus, with the matrix based version, there'll definitely be people to request matrices of higher dimension than 2.

Further, I could imagine something like

<counter COUNTER_latin>

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

/ items = sequence(1, 2, 3)

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

/ items = replace(1, 2)
/ itemselect = replace|noreplace|permute|...

</counter>

For each draw, the counter would select a new "/ items" list, commit the current draw on this list and return the value. If "permute" is selected as the item select mode, Inquisit would iterate through the "/ items" lists and select a new element from the first list on every draw, from the second list only every 4th draw, from the third list every 4*3th draw, from the fourth list every 4*3*5th draw.

Just a thought,
Malte

Of course you are absolutely right, Sean. And obviously I didn't think things through properly, thus causing confusion and dismay with my nonsensical post. Clearly, we're neither dealing with a bug nor a design issue -- the only thing that's wrong is my flawed logic (yes, my existence is undeniable proof of Unintelligent Design!). Sincere apologies to everyone for that.

That said, great suggestions presented by you and Malte to possibly make factorial selection easier to implement in a future release!

However, to make up for this utter f*ck-up on my part, and because Latin squares / factorials are a useful thing to have around, I've attached a script that should indeed produce a random, Latin square order of arbitrary size using the method described by Byers (1991).

Thanks,

~Dave

Nice!

What? Quite the contrary!

You brought this whole long thread into focus (at least for me), and my ideas for new counter syntax were stolen straight from your explanation how latin square selection should work. So, thank you!

P.S. Looking forward to seeing how you solved this.

-Sean

Ooh, the mean-spirited lawyer I keep locked up in my basement (just in case) will a have a field day with this comment!!! :-)

~Dave