Getting inaccurate .corr

Builder
1

OS (e.g. Win10): win10
PsychoPy version (e.g. 1.84.x): v2020.1.1
Hi,

The problem is that one of my key_resp.corr is not correct.

This is my test flow.
flow
In the YNtest routine, there are two response options - yes and no. Only the yes option will trigger the flowing tests. I’ve set correct answers for the YNtest and the pointest, like this

answer

The problem is that .corr for YNtest is accurate but not for pointest. In the later routine, the .corr will record it as 0 even if the response is the same as the correct answer. It will only record it as 1 when the response and the correct answer are both ‘None’… Does anyone know how to fix this? Thanks a lot.
Xiaotong

2

what keys do they press to respond?

3

Thansk for your reply @Laura_Pissani! They press ‘1’ or ‘2’ in the YNtest routine and ‘1’, ‘2’, or ‘3’ in the pointest routine.

It may worth to mention that I have a code component in the pointest routine, on each frame tab I have this

if response.keys != '1':   #response is the name of the keyboard component in the YNtest routine
    continueRoutine = False
4

Is that code working for you? (what do you want to achieve with it? that the second task is interrupted if the first answer is incorrect?)

It can be few little things, (1) check your response component and that the $column is correctly written, (2) that the key they are pressing is actually the one you coded in your conditions files, sometimes numbers in a keyboard differ from a laptop keyboard, you might wanna try the keynamefinder (when you have the program opened check the tabs at the very top, there is one called DEMOS, download it, and open Keynamefinder), (3) your answers are not written correctly in your conditions files - I am not sure what exactly is your output file giving you that you find incorrect.

1 Like
5

Laura’s right. I’d add that a useful thing to do (while debugging this sort of issue) is to print out what response.keys actually is so you can see what the if statement is testing. e.g.

print("response was:", repr(response.keys))

what do those outputs look like?

6

Thank you so much for the detailed suggestions @Laura_Pissani!

If they press ‘1’ (to indicate they’ve seen the stimulus), the following tests will be shown, otherwise they won’t see the following tests.

Seems nothing wrong in using the variables from the conditions files and their responses are correctly recorded. Here’s the result

result
result997×294 7.38 KB

7

Thanks @jon! It looks like this
response was: ‘1’
keypoint was: []
response was: ‘2’
keypoint was: []
response was: ‘2’
keypoint was: []
response was: ‘2’
keypoint was: []
response was: ‘2’
keypoint was: []
…
response is the name of the keyboard in the YNtest routine (nothing got wrong in this routine) and keypoint is the name of the keyboard in the pointest routine

8

At the point where your code is getting executed it looks like there haven’t been any keys pressed on the keypoint object. Maybe you aren’t checking if they got the right answer at the right point in time?

9

Hi jon, I have a code component in the pointest and the code is under begin routine tab. When I put it under each frame tab, I can see the keys pressed on the keypoint object.

response was: ‘1’
keypoint was: []
response was: ‘1’
keypoint was: '2’

10

Well, it can be at beginning of the routine if the keypress was in the previous routine. It might be better in End Routine if the keypress is in this routine. EveryFrame is probably more often than needed (but that depends on your study). What I’m saying is think carefully about when does the right answer need to be checked

11

When a response is given in the pointest routine of the current trial? Note, the time they can give a response is not limited.

12

Hi, @jon， when I put print("keypoint was:", repr(keypoint.keys)) in End Routine, I can find all the responses in the outputs, and these responses are the same as they are recorded in the data file. But the .corr in this routine is incorrect.

13

When I run it in pavlovia, the .corr is correct. Maybe a bug here? @jon