Hi Chris,
Two more issues with selection variables; I’ve searched the tender site without luck.
First, in this conversation –
http://help.mworks-project.org/discussions/questions/36-selection-variable-indexing
– I don’t think that he’s asking for syntax giving valueN = selectionVariable[n], I think he’s asking for selectionVariable.getNumValuesAccepted(). In other words - how many times since reset has accept() been called? In any case this would be a useful feature for me; right now I have a separate variable that I carry along for each selection var. That separate var needs to be initialized, reset, and incremented, which is doable but awkward.
Second, below I asked you some related questions:
http://help.mworks-project.org/discussions/questions/58-more-questions-from-today
But I never asked whether you need to call next_selection() after reset(). Is the selection var set to a properly randomly-chosen value after reset()?
In general - why do we need next_selection() at all? It seems that reject_selection() does everything you might need.
Thank you, best,
Mark
Hi Mark,
I think he’s asking for selectionVariable.getNumValuesAccepted(). In other words - how many times since reset has accept() been called? In any case this would be a useful feature for me; right now I have a separate variable that I carry along for each selection var. That separate var needs to be initialized, reset, and incremented, which is doable but awkward.
We can add that. I’ll open a ticket.
I never asked whether you need to call next_selection() after reset(). Is the selection var set to a properly randomly-chosen value after reset()?
No, you don’t need to call next_selection after reset. If you ask for the value of a selection variable prior to making any selections or after calling reset, then next_selection is called automatically under the hood.
In general - why do we need next_selection() at all? It seems that reject_selection() does everything you might need.
Well, one reason you need it is because (as I mentioned previously) calling accept_selections does not implicitly advance the selection variable to the next selection. Thus, you need to call next_selection explicitly.
Or am I misunderstanding your question?
Chris
Hi Chris,
Yes, what I meant is you should be able to have accept_selections advance
the selection variable, and then remove next_selection completely. I don’t
see a case where I’d want to call accept_selections and not call
next_selection, but perhaps there is something I haven’t thought of.
Best
Mark
Hi Chris,
Thanks again for your help on this - these selection variables are useful
which is why I am exploring most of the ways they can be used.
One other issue I hit today:
You added the ability for the selection variable’s values field to contain
expressions using other variables. I had assumed this was re-evaluated
every time reset_selections was called for that variable. But I think I’ve
found that the values field is only evaluated at parse time. (Which means
for us that the set of values can’t be updated as the experiment proceeds.)
Is that correct?
We don’t really need this functionality now, so if this is the way it
works, no need to change it. I might see some need for this in the future
and if so I’ll let you know.
Hope you’re having a good day and thanks,
Mark
Hi Mark,
Yes, what I meant is you should be able to have accept_selections advance the selection variable, and then remove next_selection completely. I don’t see a case where I’d want to call accept_selections and not call next_selection, but perhaps there is something I haven’t thought of.
Having separate “advance” and “next” actions can be useful, in that it lets you make multiple tentative selections and then accept (or reject) them as a group. That said, there’s no reason we couldn’t add a new action that combined the two – maybe “accept_selections_and_advance”?
You added the ability for the selection variable’s values field to contain expressions using other variables. I had assumed this was re-evaluated every time reset_selections was called for that variable. But I think I’ve found that the values field is only evaluated at parse time. (Which means for us that the set of values can’t be updated as the experiment proceeds.) Is that correct?
That’s correct. The values list is evaluated at parse time and fixed thereafter. The primary reason for this is that, when creating the selection variable, we need to know how many items the values list contains. If you set “values” to an expression like 1:n_items, then the number of items is determined by the parse-time value of n_items . Changing its value when the experiment is running has no effect on the selection variable.
Chris
Hi Chris,
Having separate “advance” and “next” actions can be useful, in that it lets you make multiple tentative selections and then accept (or reject) them as a group. That said, there’s no reason we couldn’t add a new action that combined the two – maybe “accept_selections_and_advance”?
Ok, I understand now. I don’t have any applications right now where I’d want to look at multiple selections before deciding to accept/reject, but I can see how it could be useful.
I’d be ok with accept_selections_and_advance and I’d use it.
Mark
Hi Mark,
As you suggested, I’ve added a new function, numAccepted, to the expression parser. It takes the name (as a string) of a selectable object (e.g. selection variable, block, trial) and returns the number of selections that have been accepted on it. For example:
<action type="if" tag="If done" condition="numAccepted('sel') == n_items">
...
</action>
This will be in tonight’s nightly build.
Cheers,
Chris
Hi Mark,
Regarding this:
calling accept_selections does not implicitly advance the selection variable to the next selection. Thus, you need to call next_selection explicitly.
Yes, what I meant is you should be able to have accept_selections advance the selection variable, and then remove next_selection completely. I don’t see a case where I’d want to call accept_selections and not call next_selection
I realized that I missed a key point about next_selection: It can be used only on selection variables, whereas the other selection-related actions also work on selection-enabled paradigm components (e.g. block, trial).
For paradigm components, it doesn’t matter that accept_selections doesn’t advance the selection. The selection is advanced implicitly, so there’s no need (and no way) to advance it explicitly.
While what I said previously about next_selection potentially being useful remains true, it seems clear to me now that calling accept_selections on a selection variable should advance the selection, and the fact that it doesn’t is a design flaw. Unfortunately, we can’t change that behavior now without breaking existing experiments in ways that would be difficult and tedious to fix.
As an alternative, what if we add a new attribute, advance_on_accept, to selection variables? It would be optional, with a default value of NO to preserve existing behavior. When set to YES, accept would automatically invoke next_selection, just like reject and reset do.
What do you think?
Chris
That makes sense, yes. Adding that parameter also acts as documentation that ‘accept’ doesn’t always advance.
thanks!
Mark
Hi Mark,
I’ve added the advance_on_accept parameter to selection variables, as described previously. The change will be in tonight’s nightly build.
Cheers,
Chris