Chris,
I have a few more questions after working with selection variables
today - no rush on this.
What does the property ‘nsamples’ do on a selection variable? Why
shouldn’t it just be the length of the list of possible values? In
RSVPTest.xml, nsamples is set to 1.
What is local and global variable scope? How does it interact with
range replicator variables? I remember rr’s don’t work with global
scope in some circumstances I’ve tried before.
Can add a property to have assert actions stop the experiment? We’re
not always monitoring the server console closely on all machines and
stopping it is the best way to call attention to it without bothering
the animals.
Thanks! I’m sure I’ll have a few more questions as I test this code.
best
Mark
Hi Mark,
What does the property ‘nsamples’ do on a selection variable? Why shouldn’t it just be the length of the list of possible values? In RSVPTest.xml, nsamples is set to 1.
The nsamples parameter determines how many “draws” you can make (i.e. how many times you can call next_selection) before the selection variable is exhausted and must be reset. If you’ve set the sampling method to “samples”, then typically you’d want nsamples to equal the number of values, although this is not required.
If nsamples is less than the number of values, then sequential selections effectively have their value list truncated, as you will only be able to draw the first (or last, for descending selections) nsamples items. With random selections, you draw from the full list, but only nsamples times, so random-without-replacement will never draw all the values.
If nsamples is more than the number of values, then sequential selections will wrap around to the beginning (or end, for descending selections) of the list. That is, a sequential ascending selection with values=“1,2,3” and nsamples=“5” is equivalent to one with values=“1,2,3,1,2” and nsamples=“5”. With random selections, the behavior is confusing. In either case, I wouldn’t recommend doing this.
One final detail: When the sampling method is “cycles”, the number of available draws is determined by multiplying nsamples by the number of values. If nsamples is 1 (as in RSVPDemo.xml), then using “cycles” means you get as many draws as there are values. When using sequential or random-without-replacment selection, this is probably the easiest way to ensure that you use each value exactly once before exhausting the variable.
(I’ll make separate replies for the other questions.)
Chris
Thanks Chris.
One final detail: When the sampling method is “cycles”, the number of available draws is determined by multiplying nsamples by the number of values. If nsamples is 1 (as in RSVPDemo.xml), then using “cycles” means you get as many draws as there are values. When using sequential or random-without-replacment selection, this is probably the easiest way to ensure that you use each value exactly once before exhausting the variable.
Yes this is what I wanted to know. Thanks.
Mark
What is local and global variable scope? How does it interact with range replicator variables? I remember rr’s don’t work with global scope in some circumstances I’ve tried before.
Here’s a simple rule to remember: A variable should have scope=“local” if and only if it is used as the “variable” parameter for a range or list replicator. Also, you shouldn’t use a scope=“local” variable outside of the replicator to which it’s a parameter.
Looking at the code, I get the sense that other uses for local scope have been envisioned, but as far as I know, none have been implemented.
Can add a property to have assert actions stop the experiment? We’re not always monitoring the server console closely on all machines and stopping it is the best way to call attention to it without bothering the animals.
Sure, we could add that. What kind of “stop” are you envisioning: stopping the experiment as if you’d clicked the stop button on the client, or pausing at the assertion point with the option of resuming?
Looking at the code, I get the sense that other uses for local scope have been envisioned, but as far as I know, none have been implemented.
As far as I know, it’s more of an “implemented but rarely used” type of situation.
Local variables follow “c-esque” local scoping rules. So if you set a local variable in a block, that doesn’t affect is value in an enclosing protocol, but it would apply to enclosed trial objects. It was an attempt to avoid the ills of “everything is a global” where any part of a protocol can break any other part by messing with global variables.
That said, rarely used features often get broken and never fixed, since no one notices or complains when they break. It’s certainly possible that it doesn’t still work that way.
Moreover, I believe that range replicators cannot use variables with scope “global”.
At least in the build I’m using in production right now (some 0.5dev version dated Aug 2011).
This is very helpful. Thank you!
For my purposes, it doesn’t matter. This is an assertion which should never be triggered, and if it is, you have a major error that needs to be fixed before you can successfully collect data. So I definitely don’t need the option to resume. Stopping as if you’d clicked the stop button would be fine. It would be great if a popup window could appear too so it’s obvious to the operator what went wrong.
Thanks!
M
I believe that range replicators cannot use variables with scope “global”
Yes that’s correct. In the current implementation, when the replicator replicates its contents, the variable is assigned the corresponding value in each copy within the scope of just that one copy.
Stopping as if you’d clicked the stop button would be fine. It would be great if a popup window could appear too so it’s obvious to the operator what went wrong.
OK, I’ve opened a ticket for this.
That said, rarely used features often get broken and never fixed, since no one notices or complains when they break. It’s certainly possible that it doesn’t still work that way.
I’ve only played with this a little, but it appears that it’s not possible to change the value of a local variable. See the attached experiment, which produces the following output:
00:00:16: x = 0 (16416957)
00:00:16: Setting x to 1 (16417066)
00:00:16: Value of x was changed to 1 (16417198)
00:00:16: x = 0 (16417286)
Chris
Attachment: local_scope.xml (1.05 KB)