I saw at least two people down very fast from 4.x to 3.x. Are there another potential 'leakage' method ? Or just combine public notebook by a smart way ?
", "messages": [ { "id": "1270802", "postDate": "04/12/2021 03:19:23", "content": "I saw at least two people down very fast from 4.x to 3.x. Are there another potential 'leakage' method ? Or just combine public notebook by a smart way ?
", "rawMarkdown": "I saw at least two people down very fast from 4.x to 3.x. Are there another potential 'leakage' method ? Or just combine public notebook by a smart way ?", "votes": null }, { "id": "1271214", "postDate": "04/12/2021 12:03:45", "content": "I'm one who just moved from 4.x to 3.x - no new leakage here, just a combo of a couple different methods which got much better than my previous method :)
\nA note on the leakages so far: they can provide some boost for sure, but it doesn't seem to make a huge difference if your model/technique is already good. You can get similar results without relying on the data leakage that much. (unless I'm missing something!)
\nThe biggest one seems to be that the timestamp for wifi readings wasn't reset to 0, so you can use that to get the true start time for the test paths, and slot them into where they were taken with the training paths. Even using that info can be a bit tricky though, if you assume that only one path was being recorded at a time! ;)
", "rawMarkdown": "I'm one who just moved from 4.x to 3.x - no new leakage here, just a combo of a couple different methods which got much better than my previous method :)\n\nA note on the leakages so far: they can provide some boost for sure, but it doesn't seem to make a huge difference if your model/technique is already good. You can get similar results without relying on the data leakage that much. (unless I'm missing something!)\n\nThe biggest one seems to be that the timestamp for wifi readings wasn't reset to 0, so you can use that to get the true start time for the test paths, and slot them into where they were taken with the training paths. Even using that info can be a bit tricky though, if you assume that only one path was being recorded at a time! ;)", "votes": null }, { "id": "1271266", "postDate": "04/12/2021 12:44:18", "content": "I tried the time leakage, but it didn't improve my score.
\nI didn't find any other leakage either.
It means that you can retrieve all start positions info of all test paths by using wifi timestamp ? If true, that is very big 'leakage', I though. I read some papers that say, experiments need information of initial position too. If not, the position error never bellow 2m. This also true in this competition and the 'leakage' no longer be the leakage. It is the necessary conditions !
", "rawMarkdown": "It means that you can retrieve all start positions info of all test paths by using wifi timestamp ? If true, that is very big 'leakage', I though. I read some papers that say, experiments need information of initial position too. If not, the position error never bellow 2m. This also true in this competition and the 'leakage' no longer be the leakage. It is the necessary conditions !", "votes": null }, { "id": "1271323", "postDate": "04/12/2021 13:35:26", "content": "You can get the starting timestamp, but that doesn't give you the starting position.
\nFor some test paths, you can get the initial position (by setting it to the end waypoint of the previous path). For many paths though, this is not correct - the start point of the test path is NOT the end point of the previous training path.
\nThat's why it is a bit of a leakage (because it does work for some paths), but not as good as it seems at first (because if you just set the start waypoint to the previous path's waypoint, that's incorrect)
", "rawMarkdown": "You can get the starting timestamp, but that doesn't give you the starting position. \n\nFor _some_ test paths, you can get the initial position (by setting it to the end waypoint of the previous path). For many paths though, this is not correct - the start point of the test path is NOT the end point of the previous training path.\n\nThat's why it is a bit of a leakage (because it does work for some paths), but not as good as it seems at first (because if you just set the start waypoint to the previous path's waypoint, that's incorrect)", "votes": null }, { "id": "1271351", "postDate": "04/12/2021 14:09:20", "content": "I see. Thank you !
", "rawMarkdown": "I see. Thank you !", "votes": null }, { "id": "1271353", "postDate": "04/12/2021 14:10:04", "content": "Thanks for your reply !
", "rawMarkdown": "Thanks for your reply !", "votes": null }, { "id": "1271365", "postDate": "04/12/2021 14:38:14", "content": "Same as Zidmie and chris.
", "rawMarkdown": "Same as Zidmie and chris.", "votes": null }, { "id": "1271625", "postDate": "04/12/2021 18:42:34", "content": "I also tried the time leakage. It improved my score only very slightly (about 0.03).
\nI couldn't identify any leakage (and I'm not really trying either :-) ).
\nI'm also using the snap-to-grid approach which usually improves my scores by about 0.2.
\nI'm very impressed by Mamas and Youri (and Zidmie) performance! I'm missing something they have found.
\nI keep trying new ideas :-)
@chris62 Would you like to share the score of your model without any postprocessing methods?
", "rawMarkdown": "chris62 Would you like to share the score of your model without any postprocessing methods?", "votes": null }, { "id": "1274112", "postDate": "04/15/2021 02:15:11", "content": "I don't actually track it very well, but I do know the most effective post processing is a variation of \"snap to grid\", which gives a maybe .2 or .3 boost (hard to say exact numbers - depends on a lot of things).
\nThe timestamp leakage is more like a preprocessing step for my setup - I don't actually do any post processing with that info.
", "rawMarkdown": "I don't actually track it very well, but I do know the most effective post processing is a variation of \"snap to grid\", which gives a maybe .2 or .3 boost (hard to say exact numbers - depends on a lot of things).\n\nThe timestamp leakage is more like a preprocessing step for my setup - I don't actually do any post processing with that info.", "votes": null } ], "comments": [ { "id": 1271214, "author_name": "chris62", "author_url": "", "post_date": "04/12/2021 12:03:45", "content": "I'm one who just moved from 4.x to 3.x - no new leakage here, just a combo of a couple different methods which got much better than my previous method :)
\nA note on the leakages so far: they can provide some boost for sure, but it doesn't seem to make a huge difference if your model/technique is already good. You can get similar results without relying on the data leakage that much. (unless I'm missing something!)
\nThe biggest one seems to be that the timestamp for wifi readings wasn't reset to 0, so you can use that to get the true start time for the test paths, and slot them into where they were taken with the training paths. Even using that info can be a bit tricky though, if you assume that only one path was being recorded at a time! ;)
", "votes": null, "replies": [ { "id": 1271302, "author_name": "nocturnebflat123", "author_url": "", "post_date": "04/12/2021 13:12:11", "content": "It means that you can retrieve all start positions info of all test paths by using wifi timestamp ? If true, that is very big 'leakage', I though. I read some papers that say, experiments need information of initial position too. If not, the position error never bellow 2m. This also true in this competition and the 'leakage' no longer be the leakage. It is the necessary conditions !
", "votes": null, "replies": [] }, { "id": 1271323, "author_name": "chris62", "author_url": "", "post_date": "04/12/2021 13:35:26", "content": "You can get the starting timestamp, but that doesn't give you the starting position.
\nFor some test paths, you can get the initial position (by setting it to the end waypoint of the previous path). For many paths though, this is not correct - the start point of the test path is NOT the end point of the previous training path.
\nThat's why it is a bit of a leakage (because it does work for some paths), but not as good as it seems at first (because if you just set the start waypoint to the previous path's waypoint, that's incorrect)
", "votes": null, "replies": [] }, { "id": 1271351, "author_name": "nocturnebflat123", "author_url": "", "post_date": "04/12/2021 14:09:20", "content": "I see. Thank you !
", "votes": null, "replies": [] }, { "id": 1274108, "author_name": "chenxin1991", "author_url": "", "post_date": "04/15/2021 02:06:24", "content": "@chris62 Would you like to share the score of your model without any postprocessing methods?
", "votes": null, "replies": [] }, { "id": 1274112, "author_name": "chris62", "author_url": "", "post_date": "04/15/2021 02:15:11", "content": "I don't actually track it very well, but I do know the most effective post processing is a variation of \"snap to grid\", which gives a maybe .2 or .3 boost (hard to say exact numbers - depends on a lot of things).
\nThe timestamp leakage is more like a preprocessing step for my setup - I don't actually do any post processing with that info.
", "votes": null, "replies": [] } ] }, { "id": 1271266, "author_name": "zidmie", "author_url": "", "post_date": "04/12/2021 12:44:18", "content": "I tried the time leakage, but it didn't improve my score.
\nI didn't find any other leakage either.
Thanks for your reply !
", "votes": null, "replies": [] } ] }, { "id": 1271365, "author_name": "mamasinkgs", "author_url": "", "post_date": "04/12/2021 14:38:14", "content": "Same as Zidmie and chris.
", "votes": null, "replies": [] }, { "id": 1271625, "author_name": "seuguh", "author_url": "", "post_date": "04/12/2021 18:42:34", "content": "I also tried the time leakage. It improved my score only very slightly (about 0.03).
\nI couldn't identify any leakage (and I'm not really trying either :-) ).
\nI'm also using the snap-to-grid approach which usually improves my scores by about 0.2.
\nI'm very impressed by Mamas and Youri (and Zidmie) performance! I'm missing something they have found.
\nI keep trying new ideas :-)