It seems that some customers are served more than once a week from a given depot. See for instance:
\n\ntrain[(train.ProductId == 31187) & (train.ClientId == 1064922) & (train.WeekNum == 3)]\nSorry, I renamed columns to English names, but you should get the idea.
\n\nSeems to me that these are shipments over the week, with more than one per day. I am a bit puzzled that we are asked to forecast the amount in each shipment instead of the total shipment per week.
\n\nSeems to me that it would have been good to get the day in the week of each shipment.
", "messages": [ { "id": "124725", "postDate": "06/21/2016 18:09:03", "content": "It seems that some customers are served more than once a week from a given depot. See for instance:
\n\ntrain[(train.ProductId == 31187) & (train.ClientId == 1064922) & (train.WeekNum == 3)]\nSorry, I renamed columns to English names, but you should get the idea.
\n\nSeems to me that these are shipments over the week, with more than one per day. I am a bit puzzled that we are asked to forecast the amount in each shipment instead of the total shipment per week.
\n\nSeems to me that it would have been good to get the day in the week of each shipment.
", "rawMarkdown": "It seems that some customers are served more than once a week from a given depot. See for instance:\r\n\r\n train[(train.ProductId == 31187) & (train.ClientId == 1064922) & (train.WeekNum == 3)]\r\n\r\nSorry, I renamed columns to English names, but you should get the idea. \r\n\r\nSeems to me that these are shipments over the week, with more than one per day. I am a bit puzzled that we are asked to forecast the amount in each shipment instead of the total shipment per week.\r\n\r\nSeems to me that it would have been good to get the day in the week of each shipment.", "votes": null }, { "id": "125866", "postDate": "07/03/2016 20:05:39", "content": "Yes, I noticed that. And it puzzles me too.
\n\nFor example, in the test data, for week 10, same ClientID and same ProductID, we have 6487 duplications, and for week 11, 6499.
\n\nIt does not represent so much: 0.09% of the test data, so I think we can divide the total demand for that week by the number of times the product is served on week 10 or 11.
", "rawMarkdown": "Yes, I noticed that. And it puzzles me too. \r\n\r\nFor example, in the test data, for week 10, same ClientID and same ProductID, we have 6487 duplications, and for week 11, 6499. \r\n\r\nIt does not represent so much: 0.09% of the test data, so I think we can divide the total demand for that week by the number of times the product is served on week 10 or 11.", "votes": null }, { "id": "125918", "postDate": "07/04/2016 13:23:34", "content": "I did that to establish my baseline. But now I am using the RouteId as a feature. Seems it helps a bit.
", "rawMarkdown": "I did that to establish my baseline. But now I am using the RouteId as a feature. Seems it helps a bit.", "votes": null }, { "id": "130432", "postDate": "08/06/2016 23:54:31", "content": "Hi guys. Sorry to write this late in the competition but I was looking forward to making this my first competition but then I got frustrated with the data. I went through every post and I believe this one deals best with my issue.
\n\nIt is simply what you mentioned @CPMP, that the fact that a there are duplicates in the ProductId, ClienteId and WeekNum combinations, tell us that we are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency.
\n\nThis without mentioning we are not really forecasting the true demand, but the amount delivered for that feature combinations. The only entries where the demand is truly reflected is when there are devolutions.
\n\nI don't know if I'm missing anything obvious and I know this was brought up a while ago, but if you guys could share any higher understanding of the situation or if you share my frustration it'd be moral support and I'd be extremely grateful. I'm sure I'm not a threat in the leaderboard, just wanted to have fun with this first submission.
\n\nThank you!.
", "rawMarkdown": "Hi guys. Sorry to write this late in the competition but I was looking forward to making this my first competition but then I got frustrated with the data. I went through every post and I believe this one deals best with my issue. \r\n\r\nIt is simply what you mentioned @CPMP, that the fact that a there are duplicates in the ProductId, ClienteId and WeekNum combinations, tell us that we are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency. \r\n\r\nThis without mentioning we are not really forecasting the true demand, but the amount delivered for that feature combinations. The only entries where the demand is truly reflected is when there are devolutions.\r\n\r\nI don't know if I'm missing anything obvious and I know this was brought up a while ago, but if you guys could share any higher understanding of the situation or if you share my frustration it'd be moral support and I'd be extremely grateful. I'm sure I'm not a threat in the leaderboard, just wanted to have fun with this first submission. \r\n\r\nThank you!.", "votes": null }, { "id": "130464", "postDate": "08/07/2016 11:18:31", "content": "[quote=PabloGarcia;130432]
\n\nwe are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency. \n[/quote]
\n\nOn the other hand, it does seem like we are actually predicting the demand for a product per client in a given week for 99.9% of the (test) data, no?
", "rawMarkdown": "[quote=PabloGarcia;130432]\r\n\r\nwe are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency. \r\n[/quote]\r\n\r\nOn the other hand, it does seem like we are actually predicting the demand for a product per client in a given week for 99.9% of the (test) data, no?", "votes": null }, { "id": "130466", "postDate": "08/07/2016 11:32:46", "content": "@PabloGarcia, I think you got it correctly. However, as @liviu writes, most customers have at most one delivery per week from a given depot. There is hope therefore ;)
", "rawMarkdown": "PabloGarcia, I think you got it correctly. However, as @liviu writes, most customers have at most one delivery per week from a given depot. There is hope therefore ;)", "votes": null }, { "id": "130488", "postDate": "08/07/2016 16:45:09", "content": "Thank you @liviu and @CPMP for following up. You are right in how this is relaxed in the test data, it still puzzles me me how to build a proper time series structure having multiple entrances for the same pair-key 'product-client' for a given week. I guess you can proceed as mentioned in other posts averaging or taking the median. This is probably the spiciness of this challenge, I'll try to have some fun with it. Thanks guys!
", "rawMarkdown": "Thank you @liviu and @CPMP for following up. You are right in how this is relaxed in the test data, it still puzzles me me how to build a proper time series structure having multiple entrances for the same pair-key 'product-client' for a given week. I guess you can proceed as mentioned in other posts averaging or taking the median. This is probably the spiciness of this challenge, I'll try to have some fun with it. Thanks guys!", "votes": null } ], "comments": [ { "id": 125866, "author_name": "manuelsh", "author_url": "", "post_date": "07/03/2016 20:05:39", "content": "Yes, I noticed that. And it puzzles me too.
\n\nFor example, in the test data, for week 10, same ClientID and same ProductID, we have 6487 duplications, and for week 11, 6499.
\n\nIt does not represent so much: 0.09% of the test data, so I think we can divide the total demand for that week by the number of times the product is served on week 10 or 11.
", "votes": null, "replies": [] }, { "id": 125918, "author_name": "cpmpml", "author_url": "", "post_date": "07/04/2016 13:23:34", "content": "I did that to establish my baseline. But now I am using the RouteId as a feature. Seems it helps a bit.
", "votes": null, "replies": [] }, { "id": 130432, "author_name": "pablogj01", "author_url": "", "post_date": "08/06/2016 23:54:31", "content": "Hi guys. Sorry to write this late in the competition but I was looking forward to making this my first competition but then I got frustrated with the data. I went through every post and I believe this one deals best with my issue.
\n\nIt is simply what you mentioned @CPMP, that the fact that a there are duplicates in the ProductId, ClienteId and WeekNum combinations, tell us that we are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency.
\n\nThis without mentioning we are not really forecasting the true demand, but the amount delivered for that feature combinations. The only entries where the demand is truly reflected is when there are devolutions.
\n\nI don't know if I'm missing anything obvious and I know this was brought up a while ago, but if you guys could share any higher understanding of the situation or if you share my frustration it'd be moral support and I'd be extremely grateful. I'm sure I'm not a threat in the leaderboard, just wanted to have fun with this first submission.
\n\nThank you!.
", "votes": null, "replies": [] }, { "id": 130464, "author_name": "liviux", "author_url": "", "post_date": "08/07/2016 11:18:31", "content": "[quote=PabloGarcia;130432]
\n\nwe are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency. \n[/quote]
\n\nOn the other hand, it does seem like we are actually predicting the demand for a product per client in a given week for 99.9% of the (test) data, no?
", "votes": null, "replies": [] }, { "id": 130466, "author_name": "cpmpml", "author_url": "", "post_date": "08/07/2016 11:32:46", "content": "@PabloGarcia, I think you got it correctly. However, as @liviu writes, most customers have at most one delivery per week from a given depot. There is hope therefore ;)
", "votes": null, "replies": [] }, { "id": 130488, "author_name": "pablogj01", "author_url": "", "post_date": "08/07/2016 16:45:09", "content": "Thank you @liviu and @CPMP for following up. You are right in how this is relaxed in the test data, it still puzzles me me how to build a proper time series structure having multiple entrances for the same pair-key 'product-client' for a given week. I guess you can proceed as mentioned in other posts averaging or taking the median. This is probably the spiciness of this challenge, I'll try to have some fun with it. Thanks guys!
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "124725": "It seems that some customers are served more than once a week from a given depot. See for instance:\r\n\r\n train[(train.ProductId == 31187) & (train.ClientId == 1064922) & (train.WeekNum == 3)]\r\n\r\nSorry, I renamed columns to English names, but you should get the idea. \r\n\r\nSeems to me that these are shipments over the week, with more than one per day. I am a bit puzzled that we are asked to forecast the amount in each shipment instead of the total shipment per week.\r\n\r\nSeems to me that it would have been good to get the day in the week of each shipment.", "125866": "Yes, I noticed that. And it puzzles me too. \r\n\r\nFor example, in the test data, for week 10, same ClientID and same ProductID, we have 6487 duplications, and for week 11, 6499. \r\n\r\nIt does not represent so much: 0.09% of the test data, so I think we can divide the total demand for that week by the number of times the product is served on week 10 or 11.", "125918": "I did that to establish my baseline. But now I am using the RouteId as a feature. Seems it helps a bit.", "130432": "Hi guys. Sorry to write this late in the competition but I was looking forward to making this my first competition but then I got frustrated with the data. I went through every post and I believe this one deals best with my issue. \r\n\r\nIt is simply what you mentioned @CPMP, that the fact that a there are duplicates in the ProductId, ClienteId and WeekNum combinations, tell us that we are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency. \r\n\r\nThis without mentioning we are not really forecasting the true demand, but the amount delivered for that feature combinations. The only entries where the demand is truly reflected is when there are devolutions.\r\n\r\nI don't know if I'm missing anything obvious and I know this was brought up a while ago, but if you guys could share any higher understanding of the situation or if you share my frustration it'd be moral support and I'd be extremely grateful. I'm sure I'm not a threat in the leaderboard, just wanted to have fun with this first submission. \r\n\r\nThank you!.", "130464": "[quote=PabloGarcia;130432]\r\n\r\nwe are not really forecasting the demand of a product for a store (clients) in a given week, but the demand of the product for a store given a route, canal and agency. \r\n[/quote]\r\n\r\nOn the other hand, it does seem like we are actually predicting the demand for a product per client in a given week for 99.9% of the (test) data, no?", "130466": "PabloGarcia, I think you got it correctly. However, as @liviu writes, most customers have at most one delivery per week from a given depot. There is hope therefore ;)", "130488": "Thank you @liviu and @CPMP for following up. You are right in how this is relaxed in the test data, it still puzzles me me how to build a proper time series structure having multiple entrances for the same pair-key 'product-client' for a given week. I guess you can proceed as mentioned in other posts averaging or taking the median. This is probably the spiciness of this challenge, I'll try to have some fun with it. Thanks guys!" }, "source": "meta" }