![\"\"](\"https://raw.githubusercontent.com/cdeotte/Kaggle_Images/main/Feb-2023/found-clicks.png\")
Example:
\nOn the first level, you click on the notebook and the text pops up \"Found it!\"
index = train[train.text == ].index.values\n(display(train.loc[index]))\n(train.loc[index, [, , , ]].describe())\n()\n(train.loc[index-, [, , , ]].describe())\n\nThe click:\n room_coor_x room_coor_y screen_coor_x screen_coor_y\ncount \nmean - - \nstd \n - - \n% - - \n% - - \n% - - \n - \n\nvs the prior click ( on the fqid):\n\n room_coor_x room_coor_y screen_coor_x screen_coor_y\ncount \nmean - - \nstd \n - - \n% - - \n% - - \n% - - \n - \nTakeaway: Just be careful which event you are trying to pay attention to coordinates on.
\n
See discussion here: https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/384534
\nThe room coordinates shouldn't have issue #2, above, but for some reason even very clear \"must happen in an exact spot in the corner\" events like the notebook click, above, or the first ever notebook 'close' click have very strange min/max. Although the std_dev seems about right for the width of the button.
\nThe (very first) notebook close as a secondary example of the same phenomenon:
\nindex = train[(train.level == ) & (train.name == ) & (train.fqid == ) & (train.room_fqid == )].index.values\n(train.loc[index, [, , , ]].describe())\n\n room_coor_x room_coor_y screen_coor_x screen_coor_y\ncount \nmean - \nstd \n - \n% - \n% - \n% - \n - \nExample:
\nOn the first level, you click on the notebook and the text pops up \"Found it!\"
index = train[train.text == ].index.values\n(display(train.loc[index]))\n(train.loc[index, [, , , ]].describe())\n()\n(train.loc[index-, [, , , ]].describe())\n\nThe click:\n room_coor_x room_coor_y screen_coor_x screen_coor_y\ncount \nmean - - \nstd \n - - \n% - - \n% - - \n% - - \n - \n\nvs the prior click ( on the fqid):\n\n room_coor_x room_coor_y screen_coor_x screen_coor_y\ncount \nmean - - \nstd \n - - \n% - - \n% - - \n% - - \n - \nTakeaway: Just be careful which event you are trying to pay attention to coordinates on.
\n
See discussion here: https://www.kaggle.com/competitions/predict-student-performance-from-game-play/discussion/384534
\nThe room coordinates shouldn't have issue #2, above, but for some reason even very clear \"must happen in an exact spot in the corner\" events like the notebook click, above, or the first ever notebook 'close' click have very strange min/max. Although the std_dev seems about right for the width of the button.
\nThe (very first) notebook close as a secondary example of the same phenomenon:
\nindex = train[(train.level == ) & (train.name == ) & (train.fqid == ) & (train.room_fqid == )].index.values\n(train.loc[index, [, , , ]].describe())\n\n room_coor_x room_coor_y screen_coor_x screen_coor_y\ncount \nmean - \nstd \n - \n% - \n% - \n% - \n - \n\n\nIt was the prior click
\n
I think it depends on your definition of prior. Each row's click coordinates are what a user does when they see the details in the columns (of that same row). So when i see row.text == 'Found it!' then i am looking at the following screen shot. And a histogram of screen clicks for that same row are displayed below:
You are saying what I was trying to say, but more eloquently. :)
\nDo you think the 'elapsed time' number is the time up to when \"Found it!\" was printed, or the time up until they clicked again AFTER it was printed?
", "rawMarkdown": "You are saying what I was trying to say, but more eloquently. :)\n\nDo you think the 'elapsed time' number is the time up to when \"Found it!\" was printed, or the time up until they clicked again AFTER it was printed?", "votes": null }, { "id": "2145332", "postDate": "02/15/2023 00:40:02", "content": "Previously I assumed AFTER. For example I previously assumed that the time it took the user to read the message Found it! and then click the screen is the elapsed_time of the row with row.text=='Found it!' minus the elapsed_time of the previous row. However, each user index=0 has elapsed_time=0 which contradicts this assumption. So either index=0 behaves differently, or elapsed time of reading Found it! is the row after minus the current row. I will need to do some more EDA.
I'm not very sure, but my assumptions are
\nindex=0 always has elapsed_time=0Found it! and click = (elapsed_time of Found it!) - (elapsed_time of row before).@cdeotte were you able to check your assumption that elapsed time of an action is the row after minus the current row?
", "rawMarkdown": "I'm not very sure, but my assumptions are\n- Session starts from first event --> `index=0` always has `elapsed_time=0`\n- Elapsed time of an action is current row minus previous row. For example, the time user needs to read `Found it!` and click = (`elapsed_time` of `Found it!`) - (`elapsed_time` of row before).\n\n@cdeotte were you able to check your assumption that elapsed time of an action is the row after minus the current row?", "votes": null }, { "id": "2173083", "postDate": "03/08/2023 04:24:12", "content": "Hi @hoangnguyen719 , Here are my observations:
\nFirstly, I agree with the assumption that index=0 should imply elapsed_time=0. Since the beginning of the competition, there has been several discussions concerning these two features. The competition host actually confirmed what you said, see this discussion.
Then there is the elapsed_time. According to the definition, this is
\n\nthe time has passed (in milliseconds) between the start of the session and when the event was recorded
\n
So naturally, this leads to the perception that elapsed_time should increase monotonically. But, as others have pointed out, there are many exceptions which are likely caused by data error.
Lastly, regarding how elapsed_time is logged in the game. I am no java expert, but the source code of event logger seems to suggest that the start_time of an event is always nullified at the beginning of the event, and the logger just records the time it takes for the specific event to complete. See line 324 of the source code. If this interpretation is correct, then it appears that the elapsed_time is the aggregation of individual event duration.
\n\nIt was the prior click
\n
I think it depends on your definition of prior. Each row's click coordinates are what a user does when they see the details in the columns (of that same row). So when i see row.text == 'Found it!' then i am looking at the following screen shot. And a histogram of screen clicks for that same row are displayed below:
You are saying what I was trying to say, but more eloquently. :)
\nDo you think the 'elapsed time' number is the time up to when \"Found it!\" was printed, or the time up until they clicked again AFTER it was printed?
", "votes": null, "replies": [ { "id": 2145332, "author_name": "cdeotte", "author_url": "", "post_date": "02/15/2023 00:40:02", "content": "Previously I assumed AFTER. For example I previously assumed that the time it took the user to read the message Found it! and then click the screen is the elapsed_time of the row with row.text=='Found it!' minus the elapsed_time of the previous row. However, each user index=0 has elapsed_time=0 which contradicts this assumption. So either index=0 behaves differently, or elapsed time of reading Found it! is the row after minus the current row. I will need to do some more EDA.
I'm not very sure, but my assumptions are
\nindex=0 always has elapsed_time=0Found it! and click = (elapsed_time of Found it!) - (elapsed_time of row before).@cdeotte were you able to check your assumption that elapsed time of an action is the row after minus the current row?
", "votes": null, "replies": [ { "id": 2173083, "author_name": "randwlkr", "author_url": "", "post_date": "03/08/2023 04:24:12", "content": "Hi @hoangnguyen719 , Here are my observations:
\nFirstly, I agree with the assumption that index=0 should imply elapsed_time=0. Since the beginning of the competition, there has been several discussions concerning these two features. The competition host actually confirmed what you said, see this discussion.
Then there is the elapsed_time. According to the definition, this is
\n\nthe time has passed (in milliseconds) between the start of the session and when the event was recorded
\n
So naturally, this leads to the perception that elapsed_time should increase monotonically. But, as others have pointed out, there are many exceptions which are likely caused by data error.
Lastly, regarding how elapsed_time is logged in the game. I am no java expert, but the source code of event logger seems to suggest that the start_time of an event is always nullified at the beginning of the event, and the logger just records the time it takes for the specific event to complete. See line 324 of the source code. If this interpretation is correct, then it appears that the elapsed_time is the aggregation of individual event duration.