Millisecond Forums

I've done a number of test runs with that script now and am not seeing any nans under those conditions (not moving mouse and/or (near) perfect target tracking).

Perhaps it would help if you could provide some data files that show the issue. That might provide some pointers as to what may be going wrong and where.

Here's a data file with the nans. Under trialcode (column M), test 1 is the hardest and test 7 is the easiest. 

Thanks for the data -- after turning it left to right and upside down, I think the following holds:
- The "nan" issue predominantly occurs in the "slow" rotation trials, i.e. mostly trial5 to trial7. The slower the rotation speed, the higher the rate of occurrence.
- It indeed appears to be due to the participant tracking the target _perfectly_, i.e. without slipping off-target even a single time during the entire 20 seconds of rotation. The consequence is that no values/items are ever entered into the per-trial "off distance" and "off duration" <list>s.

<trial test7>
/ stimulusframes = [1 = clearscreen, innerTrack, animatedCircle7]
/ validresponse = (mousemove)
/ isvalidresponse = [
    if (trial.test7.response == "mousemove" && expressions.distance7 > parameters.targetDiscSize) {
        list.targetDistances_total.insertitem(expressions.distance7, 1);
        list.targetDistances_trial.insertitem(expressions.distance7, 1);
        list.offTargetDistance_trial.insertitem(expressions.distance7, 1);
        list.offTargetDistance_total.insertitem(expressions.distance7, 1);
        if (values.previous_targetlocation == 1) {
            values.startOffTarget = script.elapsedtime;
            values.previous_targetlocation = 0;
        } ;
        1 == 1;
    } else if (trial.test7.response == "mousemove" && expressions.distance7 <= parameters.targetDiscSize) {
        list.targetDistances_total.insertitem(expressions.distance7, 1);
        list.targetDistances_trial.insertitem(expressions.distance7, 1);
        if (values.previous_targetlocation == 0) {
            values.offDuration = script.elapsedtime - values.startOffTarget;
            list.offDurations_total.insertitem(values.offDuration, 1);
            list.offDurations_trial.insertitem(values.offDuration, 1);
            values.previous_targetlocation = 1;
        } ;
        1 == 1;
    }
]
...
</trial>

They remain empty (i.e. contain zero items), and consequently expressions.sum_offDurations_trial

<expressions>
...
/ sum_offDurations_trial = list.offDurations_trial.mean * list.offDurations_trial.itemcount
...
</expressions>

returns "not a number" ( nan ) with all the follow-on effects.

In most cases, however, it *should* be possible  to verify those instances of perfect target tracking with the data you have at hand nonetheless.
Even though expressions.timeOnTarget_trial does not capture the duration for the reason sketched out above, what *does* capture the relevant information regardless is expressions.timeOnTarget_total. To illustrate, take subject # 185835477 from your data set:



You can see the "nan" occurence in trial7, but calculating the difference between the value of expressions.timeOnTarget_total in trial7 and its value in the preceding trial verifies that the full time was spent "on target": (71018 - 51018) = 20000.

Yes, that's right, unfortunately it looks like any time there's an nan in time on target trial, expressions.timeOnTarget_total increases by 20000. You can see that in the attached file, which is only people tracing the most difficult rotation. All nans here are also accompanied by increases of 20000 in the expressions.timeOnTarget_total column, even though it's virtually impossible for anyone in this condition to be getting a perfect score. 

You ought to make use of the information in the list.targetDistances_trial.itemcount variable in addition. If the number recorded there is 0 (as it is in the case of the nans in that 2nd data set) or otherwise very low, you need to discard the data from that trial anyway.

                                                                                                                                                                                       

Thanks Dave. This is extremely helpful. Just one more question--in some cases it seems there's 'nan' in the expressions.timeOnTarget_total column as well. Do you know why that would happen? Any suggestions for how to figure out the true time on target in those situations?

Would it be possible to point me to one or two of such specific cases? It's kind of hard to figure out which ones you may mean.

Here's an example. The third column is time during trial, the fourth is total time, the fifth is the item count, and the sixth and last column is my attempt to replace the nans. As you can see, the ones near the bottom are filling in correctly, because I'm taking the difference from the total column (column four). However, the ones in the first few rows can't calculate because there's a 'nan' in the total column.

Thanks for pointing out the specific example. I think the same logic as before is applicable here as well:

The total is 79900 at the end of the 4th trial. The 4th trial's individual result is 19900. So we have:
(79900 - 19900) = 60000

That, paired with the item count data (5th column) strongly suggests perfect performance in the preceding three trials, because

(60000 / 3) = 20000