As this is another code competition where the model will need to handle new data after the competition ends, I want to remind everyone to be mindful when writing code. I've touched on this in a previous post:
\nhttps://www.kaggle.com/competitions/optiver-trading-at-the-close/discussion/457610
\nBeing careless can lead to losing months of effort, and unfortunately, it's something that happened often in the past. Take the time to write solid, test-driven code.
", "messages": [ { "id": "3017925", "postDate": "10/15/2024 11:16:58", "content": "As this is another code competition where the model will need to handle new data after the competition ends, I want to remind everyone to be mindful when writing code. I've touched on this in a previous post:
\nhttps://www.kaggle.com/competitions/optiver-trading-at-the-close/discussion/457610
\nBeing careless can lead to losing months of effort, and unfortunately, it's something that happened often in the past. Take the time to write solid, test-driven code.
", "rawMarkdown": "As this is another code competition where the model will need to handle new data after the competition ends, I want to remind everyone to be mindful when writing code. I've touched on this in a previous post:\n\nhttps://www.kaggle.com/competitions/optiver-trading-at-the-close/discussion/457610\n\nBeing careless can lead to losing months of effort, and unfortunately, it's something that happened often in the past. Take the time to write solid, test-driven code.", "votes": null }, { "id": "3017930", "postDate": "10/15/2024 11:24:38", "content": "@fritzcremer chance of error is low here as we have float32 columns here. Errors are mostly caused with improper null treatments with non-tree models. I think this is a big factor here as well.
\nAlso, chance of OOM issues are lesser here due to the API structure, but the chance of 10-minute inference could be an issue for large and complex pipelines.
Right, code-failiure is probably not as likely as with some other competitions. But still, people may implement complex pipelines and there is always to find a way to break things. People should be especially careful when they are used to comfort of normal code-competitions, which already run your code on the private test data without showing the score and tell you if it crashed or not.
", "rawMarkdown": "Right, code-failiure is probably not as likely as with some other competitions. But still, people may implement complex pipelines and there is always to find a way to break things. People should be especially careful when they are used to comfort of normal code-competitions, which already run your code on the private test data without showing the score and tell you if it crashed or not.", "votes": null }, { "id": "3018153", "postDate": "10/15/2024 14:42:04", "content": "That is a big problem in code competitions. One gets submission errors but no error statement leading to all sorts of confusion @fritzcremer
", "rawMarkdown": "That is a big problem in code competitions. One gets submission errors but no error statement leading to all sorts of confusion @fritzcremer", "votes": null } ], "comments": [ { "id": 3017930, "author_name": "ravi20076", "author_url": "", "post_date": "10/15/2024 11:24:38", "content": "@fritzcremer chance of error is low here as we have float32 columns here. Errors are mostly caused with improper null treatments with non-tree models. I think this is a big factor here as well.
\nAlso, chance of OOM issues are lesser here due to the API structure, but the chance of 10-minute inference could be an issue for large and complex pipelines.
Right, code-failiure is probably not as likely as with some other competitions. But still, people may implement complex pipelines and there is always to find a way to break things. People should be especially careful when they are used to comfort of normal code-competitions, which already run your code on the private test data without showing the score and tell you if it crashed or not.
", "votes": null, "replies": [ { "id": 3018153, "author_name": "ravi20076", "author_url": "", "post_date": "10/15/2024 14:42:04", "content": "That is a big problem in code competitions. One gets submission errors but no error statement leading to all sorts of confusion @fritzcremer
", "votes": null, "replies": [] } ] } ] } ], "raw_markdown_by_id": { "3017925": "As this is another code competition where the model will need to handle new data after the competition ends, I want to remind everyone to be mindful when writing code. I've touched on this in a previous post:\n\nhttps://www.kaggle.com/competitions/optiver-trading-at-the-close/discussion/457610\n\nBeing careless can lead to losing months of effort, and unfortunately, it's something that happened often in the past. Take the time to write solid, test-driven code.", "3017930": "fritzcremer chance of error is low here as we have float32 columns here. Errors are mostly caused with improper null treatments with non-tree models. I think this is a big factor here as well.\nAlso, chance of OOM issues are lesser here due to the API structure, but the chance of 10-minute inference could be an issue for large and complex pipelines.", "3018011": "Right, code-failiure is probably not as likely as with some other competitions. But still, people may implement complex pipelines and there is always to find a way to break things. People should be especially careful when they are used to comfort of normal code-competitions, which already run your code on the private test data without showing the score and tell you if it crashed or not.", "3018153": "That is a big problem in code competitions. One gets submission errors but no error statement leading to all sorts of confusion @fritzcremer" }, "source": "meta" }