Selection variables 2013 part 2

Mark Histed's Avatar

Mark Histed

22 Apr, 2013 01:44 PM

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

  1. Support Staff 1 Posted by Christopher Sta... on 22 Apr, 2013 05:16 PM

    Christopher Stawarz's Avatar

    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

  2. 2 Posted by Mark Histed on 22 Apr, 2013 05:47 PM

    Mark Histed's Avatar

    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

  3. 3 Posted by Mark Histed on 22 Apr, 2013 10:56 PM

    Mark Histed's Avatar

    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

  4. Support Staff 4 Posted by Christopher Sta... on 23 Apr, 2013 03:03 PM

    Christopher Stawarz's Avatar

    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

  5. 5 Posted by Mark Histed on 23 Apr, 2013 07:50 PM

    Mark Histed's Avatar

    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

  6. Christopher Stawarz closed this discussion on 20 Nov, 2013 03:55 PM.

  7. Support Staff 6 Posted by Christopher Sta... on 01 May, 2014 07:33 PM

    Christopher Stawarz's Avatar

    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

  8. 7 Posted by mhisted on 02 May, 2014 04:06 PM

    mhisted's Avatar

    Thanks, Chris.

  9. Support Staff 8 Posted by Christopher Sta... on 06 May, 2014 01:51 PM

    Christopher Stawarz's Avatar

    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

  10. 9 Posted by mhisted on 06 May, 2014 06:29 PM

    mhisted's Avatar

    That makes sense, yes. Adding that parameter also acts as documentation that 'accept' doesn't always advance.

    thanks!
    Mark

  11. Support Staff 10 Posted by Christopher Sta... on 07 May, 2014 03:48 PM

    Christopher Stawarz's Avatar

    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

  12. Christopher Stawarz closed this discussion on 15 May, 2014 01:31 PM.

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