Two quick questions

Yasmine El-Shamayleh's Avatar

Yasmine El-Shamayleh

27 May, 2021 02:37 PM

Hi Chris -

I'm continuing to adapt the example code you sent me (attached) and had a few questions:

(1) I dont see where in the protocol the parameter "num_accepted" is updated
(2) How do I adapt this code to show multiple repeats of the image set?

In looking over other example code provided with the install, I think you achieved point #2 above via the "when..." conditional in the final state of RSVPdemo.mwel :
      state 'RSVP complete' {
            report ('********* RSVP Trial Completed *********')
            sync = 0
            goto (
                target = 'RSVP start'
                when = image_set_repeat_count < image_set_repetitions
                )
            yield ()

But I'm not sure how that "when..."would interfere with the current "when..."conditional in the final state of example1.mwel:

    state 'End trial' {
            wait (inter_trial_interval)
            // If there are more images to show, start a new trial
            goto (
                target = 'Begin trial'
                when = num_accepted('image_index') < image_set_size
                )
            // Otherwise, exit the task
            yield ()

How do I correctly "loop" over two things? Image set size AND repetition set size?

Thank you!
Yasmine

  1. Support Staff 1 Posted by Christopher Sta... on 27 May, 2021 03:23 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    (1) I dont see where in the protocol the parameter "num_accepted" is updated

    num_accepted is a function, not a variable. If you pass it the name of a selection variable as a string ( 'image_index' in your example experiment), it returns the number of accepted selections made on the variable. The current value of image_index itself is controlled by the invocations of reset_selection, next_selection, accept_selections, and reject_selections throughout the protocol.

    If you want more info on how MWorks' selection mechanism works in general, there's a section on it in the user manual.

    (2) How do I adapt this code to show multiple repeats of the image set?

    Your reading of RSVPDemo is correct. To implement the same logic in example1, you need to add states at the beginning and end of the task to handle the image set repetition. I've attached an updated MWEL file that includes this change.

    Cheers,
    Chris

  2. 2 Posted by Yasmine El-Sham... on 27 May, 2021 05:19 PM

    Yasmine El-Shamayleh's Avatar

    Great - thanks Chris! Will work through all of this very shortly!
    Yasmine

  3. 3 Posted by Yasmine El-Sham... on 08 Jun, 2021 11:28 PM

    Yasmine El-Shamayleh's Avatar

    Hi Chris -

    Since implementing the "image set repetitions" functionality in the
    example1.mwel, I've noticed two types of errors come up on the "Server
    Console" - although neither of them interfere with the progress of the
    experiment.

    (1) ERROR: There are no more items left to draw [line 191: column 13]

    In my code, this line is the beginning of the "Stim on" state. My
    understanding is that the code should only jump back to the "Stim on" state
    if there ARE stimuli left to draw at the end of a trial - so Im not quite
    sure why this is happening. Any ideas how to troubleshoot?

    (2) An error warning that we skipped a screen refresh

    Sorry I don't have the exact wording - but wondering why this is happening
    and if we can do anything about it. It's rare - but thought I'd point
    it out.

    Thanks!
    Yasmine

  4. Support Staff 4 Posted by Christopher Sta... on 09 Jun, 2021 12:56 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    (1) ERROR: There are no more items left to draw [line 191: column 13]

    This happens when you invoke next_selection after all selections have been exhausted. In the updated example I sent you, the state "End trial" checks whether all selections are exhausted and, if so, ends the current image set repetition:

    // If there are more images to show, start a new trial
    goto (
        target = 'Begin trial'
        when = num_accepted('image_index') < image_set_size
        )
    // Otherwise, end the current image set repetition
    goto ('End image set repetition')
    

    On the other end, the state "Begin image set repetition" invokes reset_selection to reset the selection variable for the next image set repetition:

    reset_selection (image_index)
    

    If your code includes both those pieces and you're still seeing the error, you can send me your MWEL, and I'll try to spot the problem.

    (2) An error warning that we skipped a screen refresh

    This means that, for some reason, MWorks wasn't able to update the screen on a particular display refresh. Seeing this rarely isn't cause for concern. There are many reasons why the system might experience an occasional performance "hiccup", and I wouldn't spend time trying to track down the (presumably transient) cause of these events.

    However, if these warnings show up frequently, it means the graphics hardware is having trouble keeping up with MWorks' needs. In that case, the problem might lie in MWorks. It also might be due to another application or process, or it could reflect an issue in the system's graphics drivers. If you ever find yourself in this situation, let me know, and I can help you troubleshoot.

    Cheers,
    Chris

  5. 5 Posted by Yasmine El-Sham... on 21 Jun, 2021 09:24 PM

    Yasmine El-Shamayleh's Avatar

    Hi Chris -

    Following up on my email below about the error I'm getting in relation to
    calling next_selection when there are no more stimuli to draw:

     ERROR: There are no more items left to draw [line 191: column 13]

    Any chance you spotted the error in my code?

    Thank you!
    Yasmine

  6. Support Staff 6 Posted by Christopher Sta... on 22 Jun, 2021 12:13 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    Any chance you spotted the error in my code?

    Sorry, I never received your code. Can you try sending it again?

    FYI, attachments with the extension ".mwel" sometimes cause emails to be treated as spam and lost. To avoid this, I recommend either adding a ".txt" extension to or ZIP compressing MWEL files before attaching them to an email. Sorry for the hassle!

    Thanks,
    Chris

  7. 7 Posted by Yasmine El-Sham... on 22 Jun, 2021 01:01 PM

    Yasmine El-Shamayleh's Avatar

    Ah! Good to know. Re-attaching here as .txt.

    Please let me know if you can access this.

    Thanks!
    Yasmine

  8. Support Staff 8 Posted by Christopher Sta... on 22 Jun, 2021 03:14 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    Thanks, I received it this time. There is an issue, but I think it's in my original version, too. I'll let you know once I've sorted it out.

    Chris

  9. Support Staff 9 Posted by Christopher Sta... on 28 Jun, 2021 09:46 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    My apologies. The "no more items left to draw" message was due to an error on my part in the original example experiment. To resolve the issue, you need to make two changes.

    First, in the definition of image_index, add the parameter advance_on_accept with value YES:

    selection image_index (
        values = 0 : image_set_size - 1
        selection = random_without_replacement
        advance_on_accept = YES  // This is the line to add
        )
    

    Second, in the state "Stim on", replace

    next_selection (image_index)
    

    with

    if (images_shown > 0) {
        next_selection (image_index)
    }
    

    I've attached a copy of your experiment file that includes these changes. With this version, you should no longer see the error message.

    As for why these changes are necessary: Selection variables are confusing (even to me), because sometimes they advance automatically to the next selection, and sometimes they don't. Specifically:

    • reset_selections does not automatically make a next selection. Immediately after being reset, a selection variable is in the "no selection" state. To make an initial selection, you have to either (1) invoke next_selection explicitly or (2) just use the variable, as asking for the value of a selection variable in the "no selection" state causes a selection to be made automatically for you. Personally, while I think (1) is totally reasonable and expected, (2) is not so expected and a little unnerving. However, it doesn't really matter in practice, because in both cases, you end up making one, initial selection.

    • By default, accept_selections also does not make a next selection. However, unlike reset_selections, accept_selections doesn't cause the selection variable to enter the "no selection" state. Rather, it leaves the current, just-accepted selection in place. You can alter this behavior by setting advance_on_accept to YES, in which case accept_selections does make a next selection.

    • Finally, reject_selections always makes a next selection.

    When writing the example for you, I forgot that reject_selections makes a next selection. This meant that, when a trial failed before the current image set repetition was complete, the selection variable was advanced twice when it should have been advanced only once: implicitly by reject_selections, and explicitly by the next_selection invocation in state "Stim on". This resulted in the first of those two selections (i.e. images) never being used, and it caused the next trial to "consume" more than images_per_trial images, which in turn led to later trials running out, hence the "no more items left to draw" error. The changes I outlined above fix the problem by

    1. making both accept_selections and reject_selections automatically make a next selection and
    2. explicitly invoking next_selection only when not at the beginning of a trial.

    If you think this all sounds ridiculous and highly conducive to errors, I agree! I didn't implement selection variables, and if I could re-make them from scratch, they would never implicitly make a next selection. However, I can't change their behavior now, because doing so would break the many, many experiments that are designed around and depend on the existing behavior. I suppose I could make a new, alternative selection variable that behaves in ways that I find sensible, but that might just muddy the waters further.

    If you have any suggestions for how to improve this situation, please let me know! In the meantime, the changes I described should make the selection-variable bits of your experiment work correctly.

    Cheers,
    Chris

  10. Support Staff 10 Posted by Christopher Sta... on 29 Jun, 2021 12:14 PM

    Christopher Stawarz's Avatar

    I've attached a copy of your experiment file that includes these changes.

    For some reason, the attachment failed to upload. Trying again.

  11. Support Staff 11 Posted by Christopher Sta... on 29 Jun, 2021 12:21 PM

    Christopher Stawarz's Avatar

    if I could re-make them from scratch, they would never implicitly make a next selection. However, I can't change their behavior now, because doing so would break the many, many experiments that are designed around and depend on the existing behavior.

    Now that I've vented my frustrations, it occurs to me that I could just add a new parameter that enables alternative, more predictable behaviors for selection variables. That would avoid breaking existing experiments, while allowing new ones to opt in to the new behaviors. That's probably what I'll do.

    Chris

  12. 12 Posted by Yasmine El-Sham... on 01 Jul, 2021 12:53 AM

    Yasmine El-Shamayleh's Avatar

    Hi Chris.,

    Super - I received your detailed commentary on that next selection error
    and will work through it today! And sounds good about a new parameter for
    getting more predictable behaviors for selection variables!

    Thank you,
    Yasmine

  13. 13 Posted by Yasmine El-Sham... on 01 Jul, 2021 12:59 AM

    Yasmine El-Shamayleh's Avatar

    Hi Chris -

    I made the two changes you suggested:

    *CHANGE 1*
    selection image_index (
        values = 0 : image_set_size - 1
        selection = random_without_replacement
        advance_on_accept = YES //Y: Added this line to
    get rid of "ERROR: no more items left to draw"
        )
    *CHANGE 2*
    state 'Stim on' {
                if (images_shown > 0){ //Y: Added this line to
    get rid of "ERROR: no more items left to draw"
                    next_selection (image_index)
                }

    Last night, I ran the code with mouse simulation in eyelink, without moving
    the mouse -- and didn't see the error come up. But today, we ran an animal
    and we did get the error. I suspected that this was due to breaking
    fixation and the state called "Trial failure" which also contains a
    "reject_selections (image_index)". To confirm, I re-ran eyelink with mouse
    simulation and then introduced some simulated broken fixations...and sure
    enough, I got the error again.

    I do think the error is less frequent than it was previously...but Im
    wondering if we should edit the "Trial failure" state?

    Thanks!
    Yasmine

  14. Support Staff 14 Posted by Christopher Sta... on 02 Jul, 2021 12:37 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    Yes, it was reject_selections in the "Trial failure" state that triggered the error. I thought my changes had fixed that, but it sounds like they haven't.

    Can you send me the exact experiment file you're having problems with? Maybe there's another issue I missed.

    Thanks,
    Chris

  15. 15 Posted by Yasmine El-Sham... on 02 Jul, 2021 08:26 PM

    Yasmine El-Shamayleh's Avatar

    Hi Chris -

    Attaching the most recent version of our code (and %include files) in a
    compressed folder.

    Thank you,
    Yasmine

  16. Support Staff 16 Posted by Christopher Sta... on 06 Jul, 2021 03:43 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    Thanks for sending your code.

    I don't see any issues with your selection-variable logic. The only problem I see is that the value of images_per_trial (3) doesn't divide evenly in to image_set_size (100). This means that you will run out of selections at the end of the image set repetition, regardless of whether you enter the "Trial failure" state or not.

    Can you try setting image_set_size to 99? I think that will eliminate the error messages.

    Cheers,
    Chris

  17. 17 Posted by Yasmine El-Sham... on 06 Jul, 2021 04:07 PM

    Yasmine El-Shamayleh's Avatar

    Ah! Interesting clue.

    I tried setting it to 99 - and sure enough no errors. That said, Im
    not sure this is a good solution as different animals will be able to
    fixate a different number of stimuli per trial (typically 3-5 stimuli) so
    we'll always get this error eventually.

    Two thoughts:

    (1) How does MWorks currently handle this error? The console displays the
    error - but the experiment continues to run. Is the next trial (which
    doesn't have enough images) shorter? Or does MWorks add new stimuli?

    (2) What's a good way to solve this problem, we thought of two options:

    Option 1: when there are an insufficient number of stimuli to draw for the
    next trial, MWorks can just display whatever stimuli are available. This is
    simple enough - but might throw animals off by introducing unexpected
    rewards.

    Option 2: when there are an insufficient number of stimuli to draw for the
    next trial, MWorks can just randomly draw stimuli from the image set to
    achieve the required number of stimuli per trial.

    Thoughts on this?
    Yasmine

  18. Support Staff 18 Posted by Christopher Sta... on 07 Jul, 2021 02:55 PM

    Christopher Stawarz's Avatar

    Hi Yasmine,

    Im not sure this is a good solution as different animals will be able to fixate a different number of stimuli per trial (typically 3-5 stimuli) so we'll always get this error eventually.

    It doesn't have to work that way. That's just how I designed the example experiment.

    How does MWorks currently handle this error? The console displays the error - but the experiment continues to run. Is the next trial (which doesn't have enough images) shorter? Or does MWorks add new stimuli?

    If a selection variable runs out of selections, its value won't change until you reset it. This means your experiment will keep showing the last selection (i.e. image) on every subsequent trial.

    What's a good way to solve this problem, we thought of two options:

    Option 1: when there are an insufficient number of stimuli to draw for the next trial, MWorks can just display whatever stimuli are available. This is simple enough - but might throw animals off by introducing unexpected rewards.

    Option 2: when there are an insufficient number of stimuli to draw for the next trial, MWorks can just randomly draw stimuli from the image set to achieve the required number of stimuli per trial.

    Either approach will work. The choice depends on your priorities. Do you want the animal to fixate on each image in the image set a specific, fixed number of times? Or do you want them to perform a certain number of fixed-length trials and don't care how many times they see a particular image, so long as no image repeats until they've seen the complete set? Each approach requires only minor changes to your experiment. Basically, you'll just be adding another test of

    num_accepted('image_index') < image_set_size
    

    somewhere and taking appropriate action (ending the trial or resetting the selection variable).

    If you tell me how you want it to work, I'll send you an updated example.

    Cheers,
    Chris

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

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