More about selection variables
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
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Christopher Sta... on 13 Apr, 2012 03:39 PM
Hi Mark,
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
2 Posted by Mark Histed on 13 Apr, 2012 03:53 PM
Thanks Chris.
Yes this is what I wanted to know. Thanks.
Mark
Support Staff 3 Posted by Christopher Sta... on 13 Apr, 2012 03:57 PM
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.
Support Staff 4 Posted by Christopher Sta... on 13 Apr, 2012 04:00 PM
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?
5 Posted by Dave Cox on 13 Apr, 2012 04:06 PM
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 enclosingprotocol
, but it would apply to enclosedtrial
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.
6 Posted by Mark Histed on 13 Apr, 2012 05:08 PM
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).
7 Posted by Mark Histed on 13 Apr, 2012 05:08 PM
This is very helpful. Thank you!
8 Posted by Mark Histed on 13 Apr, 2012 05:12 PM
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
9 Posted by Dave Cox on 13 Apr, 2012 06:33 PM
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.
Support Staff 10 Posted by Christopher Sta... on 13 Apr, 2012 07:38 PM
OK, I've opened a ticket for this.
Support Staff 11 Posted by Christopher Sta... on 13 Apr, 2012 07:57 PM
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:
Chris
Christopher Stawarz closed this discussion on 01 May, 2012 02:40 PM.
Christopher Stawarz closed this discussion on 20 May, 2016 02:15 PM.