Millisecond Forums

Dammit again -- I even have a demo script for this around (conceived for a recent Inquisit programming workshop). See attached.

~D.

Wait, you mean this

/ not = (counter1, counter2, counter3)

is different from this

/ not = (counter1)
/ not = (counter2)
/ not = (counter3)

D'oh! My bad... but, you know, this exactly resembles what I referred to in my rant about people's usage of Inquisit (see the wishlist posting). I'd rather opt for fixing and straightening out the current pitfalls (includes overhauling the help) instead of ever adding sophisticated functionality that entails inconsistencies. Please do not take me wrong, I am not at all complaining. Inquisit is a great piece of software that reduces the idea-to-lab time significantly for everybody using it but I just like well documented software that behaves consistently under all circumstances more than those feature packed, yet unpredictable monstrosities.

That said, thanks a lot for that great hint, Dave!

Agreed!

Again, I cannot tell you whether these should lead to different results by design (IMO they should not), all I can tell you is that (2) will work whereas (1) will not.

~Dave

That brings back an idea I had a while ago when we hired four new
student staff members who had to learn Inquisit. I then thought about
setting up a Wiki from the help (only for internal purposes) where
everybody could add examples, give tips, point out caveats and so forth.

Question
to Sean: Would turning the help into a Wiki or at least supplementing
the help with a Wiki be an option for you? I can envision Dave and
myself taking part in this. All those little notes we users have flying
around about what to do and what better not do do would be a valuable
addition to the help, I suppose. Some of the more obscure options
like"constant" (not explained in the help), the new keyboard scan codes
(not contained in the help), the unit specifiers (cannot find them in
the help), and much more could all be covered more optimally and
thoroughly with distributed resources. I as a spare time software
developer know how tedious writing the help is. That's the one thing
that always falls off the shelf but which is most important to users.

Bye, Malte.

Your point is taken, and I certainly agree. Personally, I think a "sophisticated" feature is justified only if it simplifies the programming required to achieve a particular kind of task or paradigm. In other words, if a feature allows the programmer to write less complicated scripts, then it's a good feature.

I also consider removing ambiguities from the language to be a priority, and I don't think it's incompatible with adding new functionality.

And yes, the two examples of multiple "not" should be equivalent. I'm guessing the case with multiple /not commands simply overwrite each other as this is the default behavior when multiple attributes are listed. I'll file a bug on that.

Thanks,
Sean

I need to clear that up before something goes wrong: It's exactly the other way round: Multiple /not attributes work *fine*

/ not = (counter1)
/ not = (counter2)
/ not = (counter3)

The problematic case is

/ not = (counter1, counter2, counter3)

~Dave

Ok, I think the only bug is in the documentation, because I've checked both cases and they be have identically as we all would expect. Are either of you seeing different behaviors?

-Sean

Okay, here we go: I had initially discovered the inconsistency between '/ not = (a, b, c, d)' and '/ not = a, / not = b, / not = c, / not  = d' when writing and testing the SOPT script. The Inquisit versions used at the time were 3.0.3.2 and various beta builds of 3.0.4.0. To recap the then-finding once again: Multiple '/ not ' attributes worked fine while the same logic implemented via a single '/ not = (a, b, c, d)' would lead to faulty results (double selections, etc.).

I've now revisited this scenario with version 3.0.5.0 and found that indeed -- as Sean noted -- both options behave equally in this version. However they behave equally *wrong*, i.e. there'll now be undesired, faulty selections in both cases. Bummer. A set of example scripts showcasing the problem for both not-options is attached to this message.

~Dave

Yep, same here. The reason for my disbelieving response to Dave's posting was that I had tested both variants and was pretty sure they yielded the same undesired results. However, I tend to believe the things Dave states, so I tried both options on one of our lab computers which indeed delivered. But: my notebook - Inquisit 3.0.5.0, lab computer - 3.0.3.2. So Dave's correct, version 3.0.3.2 respects multiple "/ not" statements but not a single "/ not" statement, whereas version 3.0.5.0 disregards both cases.

Malte.

Some more details about the code attached to my previous post to help in troubleshooting the issue. The code in the examples is essentially supposed to generate a random, n-th order Latin square (over the course of n trials, although this is not essential). Here's an example and outline of the underlying reasoning for the case of n=4 elements:

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

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

<counter c>
/ items = (1,2,3,4)
/ select = noreplace
/ not = (a, b)
[...]
</counter>

<counter d>
/ items = (1,2,3,4)
/ select = noreplace
/ not = (a, b, c)
[...]
</counter>

Over the course of 4 trials, this is what's supposed to happen:

(1) Trial 1

• A random value (e.g. 3) is drawn from <counter a>, leaving three values in its selection pool for the subsequent trial (1,2,4).


• A random value is drawn from <counter b>, whereas it shall not be the same value previously drawn from <counter a>. The value drawn might be 1, also leaving three values in the counter's selection pool for the subsequent trial (2,3,4).


• A random value is drawn from <counter c>, whereas it shall not be identical to the value drawn from either <counter a> and <counter b>. Thus the value determined might be 4, with again three values remaining in <counter c>'s selection pool (1,2,3).


• A value is drawn from <counter d>. Given the imposed selection constraints, this value must be 2, with values (1,3,4) remaining in <counter d>'s selection pool.

(2) Trial 2

• A value is selected from <counter a>. Since 3 has already been selected on the previous trial, this value might be 1, with (2,4) remaining in the selection pool for the third trial.


• A random value is drawn from <counter b>. 1 has been selected previously and the value shall not be identical to <counter a>'s current selection (1). So let's say the returned value from <counter b> is 3, leaving its selection pool at (2,4).


• <counter c> now has little options left: 4 has been selected on the previous trial, and due to the constraints 1 (<counter a>) and 3 (<counter b>) are also out of the picture. The returned value thus must be 2, with (1,3) remaining for subsequent trials.


• Again, the selection for <counter d> is fully determined at this point: 2 has been selected previously, and due to selection constraints 1,2, and 3 aren't available either. The value drawn can only be 4, leaving <counter d>'s selection pool at (1,3).

You get the idea... Summing up, over the course of 4 trials, here's the desired result (along the lines of the above example) in cross-tabulated form, with trial numbers as rows and counter selections as columns:

counter
a b c d

t1  3 1 4 2
t2  1 3 2 4
t3  4 2 1 3
t4  2 4 3 1

As we can see, we (should) have ended up with a nice, randomly generated Latin square. Now, if only this would (still) work. I've found the outlined counter-logic to function properly for smaller values of n (e.g. up to 4) even in 3.0.5.0 and the release 3.0.4.0 build, but according to my tests it fails miserably for larger values in both. As Malte confirmed (thanks!) the issue is not present in 3.0.3.2. However I am *very* sure that multiple '/ not' statements vs a single '/ not = (a,b,c,d,...)' did make a difference in 3.0.3.2 -- note that this might hold true for larger values of n only.

Thanks for enduring this tedious-to-read post!

~Dave