Millisecond Forums

> How could that be possible?

If you modified the script, it's possible that you introduced a mistake. I'd have to see the actual script you used as well as a raw data file including ostensibly wrong values for the correctness.

I modified the script, but only the stimuli items. Attached please find the script and one output file. The participant was in experimental condition 1 (blue [_b] is associated with pulling, yellow [_y] with pushing). I highlighted the trials in which the inital and the final response were correct, no change of direction emerged, but still the trials were considered incorrect.

Thanks for attaching the script and example data. So far I have not discovered any obvious issue in the code (and I haven't been able to produce inconsistent results using the script either yet). One thing I can imagine happening is some sort of physical problem with the mouse. For an optical mouse, imagine it getting moved past the pixel tolerance, thus making the /isvalidresponse logic fire, then the sensor hits a spec of reflective surface or other obstruction, making the mouse briefly "jump" to different coordinates, causing the /iscorrectresponse logic to rate the response as wrong, once past the obstruction and back at the proper coordinates things proceed normally (i.e. no direction changes detected).

This, of course, only "works" as an explanation if the ostensible inconsistencies are relatively rare in the overall data. If they are more frequent and happened across subjects tested on different computers in different locations, it would seem far-fetched as an explanation. Can you give me a sense of the frequency of the problem and the situation under which the tests occurred?

Thanks for your response and apologies for the late reply. We also thought of a physical problem as most participants probably used optical mouse. The error occurred in 495 (out of 15.731) trials (=3,1%), however, it occurred in two thirds of our participants. Thus, although the error is rather rare in the overall data, it is not rare across participants. We tested the AAT, counting the change of directions and error messages. The error also occurred in our data and this was always the case when the direction was changed once (although the output file indicated no change of direction). Any ideas?

Thanks for the additional information -- I agree, that makes some kind of physical problem with the mouse a lot less likely. I must be missing some kind of edge-case in the code (i.e. some rare, specific set of conditions under which no change of direction is detected or the initial response is somehow misclassified), but having review the code again over the past couple of hours, I'm still not seeing where exactly things could go wrong. Maybe it has to do something with how the canvas aspect ratio works out mathematically on specific displays.

If you have the time, could you perform a test run with the attached script on a system where you observed the issue? It would be great to capture at least a few erroneous trials with that script -- it is identical to yours, except it logs a lot more information (e.g. the mouse y coordinates at every single in- or decrease step). That might help me pinpoint what exactly is happening and where.

Hi Dave,

we performed the AAT with the script you sent us, please fine the output attached. Hopefully, it yields some clarification.

Best
Charlotte

Hi! I posted the output file several days ago. Can you estimate how long it will take to check the file?

Thanks a lot and best
Charlotte

Sorry for the delay. I have looked at that file at considerable length:
(1) The coordinates look fine, i.e. they are exactly within the ranges they'd be expected to be given the screen and canvas size.
(2) As far as I can see, that data file does not show the issue, i.e. all initial responses, final responses and direction changes logged are consistent / what they should be. As such, that particular data file is of less diagnostic value than a file that contains (seemingly?) inconsistent data.
(3) The only thing that sticks out in the data is that -- on a few, rare occasions -- there are fairly large jumps in terms of the absolute distance (in pixels) the mouse moves within a single trial. That may suggest either extremely rapid movement (perhaps quicker than the program can reliably detect) or some other problem. That may have something to do with the original problem, but given (2) it's not clear.

If you have a data file with extended logging around that _does_ contain inconsistent trials (i.e. initial and final response differ, but no direction change indicated), that would be helpful. Thanks!

Hi Dave, sorry, I didn´t check the file as I was sure that the error would occur. Please find attached an output file in which the problem occurs.

Best
Charlotte