{
  "id": 21620,
  "title": "Interpretation/Overview of the flow",
  "url": "/competitions/grupo-bimbo-inventory-demand/discussion/21620",
  "author_name": "",
  "post_date": "2016-06-12T12:27:43.027Z",
  "votes": 14,
  "comment_count": 3,
  "views": 1168,
  "content": "<p>(look at the bottom of this post for the picture overview)</p>\n\n<p><em>N.B: still pending: returns next week interpretation.</em></p>\n\n<p>Used only Sales_Depot_ID &lt; 1120 (2.7M rows) to understand how the data is structured, in addition to the instructions provided in the Data page. A picture is better than a thousand words here. I might be wrong on some parts (and there are parts I am guessing what is missing), I just made it very quickly to get an overview. I used simple knowledge from Accounting Management for this (it seems to be a very simple task, except you have Products showing up out of nowhere you must take care of). Some products are interchangeable just by a multiplier.</p>\n\n<p>As the returns is delayed by 1 week (obvious and typically normal for that), it is not practical to use the first week as training. Either you lag everything by 1 week (which is feasible but you'd still lose 1 week in training), either you find a way to incorporate N-1 information in the first week which is not provided (which requires forecasting and potentially biases your final model).</p>\n\n<p>I think a good starting model would encompass:</p>\n\n<ul>\n<li>By Depot_ID</li>\n<li>By normalized + aggregated type of product (pasta weight in grams, breakfast chocolate in grams, etc.)</li>\n<li>By exploiting the potential of forecasting the initial stock for the first week (the latter could have a very large impact on the model)</li>\n</ul>\n\n<p>i.e better work on the products first than working on forecasting straight away. A good product dictionary should blow up a best dumb model by far in the experiences I had in forecasting stock in businesses. However, overfitting is a serious issue here due to the time size. Just looking at the data and testing some &quot;dumb&quot; models, a model loss of an additional (+-)35% can hold true (like: last week -&gt; Public LB (Public LB is week N+1?) ), but the average should lower this variation by far enough. If you go pure mathematical methods (own customized ML methods), try to aim under a relative 35% error at least (same threshold of a dumb model) for each week. The error should average out under 35% error thanks to the highly demanded products. (Someone can verify the threshold of 35%? I used only 2.7M rows.)</p>\n\n<p>As typical for commodities provisioning, it is better to over-provision (one-sided loss: pick back products and re-sell their elements for money) than under-provision (two-sided loss: for the client and for the provider) the stock. Thus the RMSLE which <a href=\"https://www.kaggle.com/laurae2/grupo-bimbo-inventory-demand/rmsle-loss-spread/output\">punishes faster</a> under-provisioning (higher cost) than over-provisioning (lower cost).</p>\n\n<p>Those who use xgboost (or any method which can change the loss function): don't forget to set the loss function accordingly (and to cap the lower tail which makes the gradient <em>explode</em>).</p>\n\n<p><img src=\"https://www.kaggle.com/blobs/download/forum-message-attachment-files/4405/Overview.JPG\" alt=\"Overview\" title></p>\n\n<p><img src=\"https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot001.png\" alt=\"enter image description here\" title></p>\n\n<p><img src=\"https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot002.png\" alt=\"enter image description here\" title></p>",
  "messages": [
    {
      "id": "123516",
      "postDate": "06/12/2016 12:27:43",
      "content": "<p>(look at the bottom of this post for the picture overview)</p>\n\n<p><em>N.B: still pending: returns next week interpretation.</em></p>\n\n<p>Used only Sales_Depot_ID &lt; 1120 (2.7M rows) to understand how the data is structured, in addition to the instructions provided in the Data page. A picture is better than a thousand words here. I might be wrong on some parts (and there are parts I am guessing what is missing), I just made it very quickly to get an overview. I used simple knowledge from Accounting Management for this (it seems to be a very simple task, except you have Products showing up out of nowhere you must take care of). Some products are interchangeable just by a multiplier.</p>\n\n<p>As the returns is delayed by 1 week (obvious and typically normal for that), it is not practical to use the first week as training. Either you lag everything by 1 week (which is feasible but you'd still lose 1 week in training), either you find a way to incorporate N-1 information in the first week which is not provided (which requires forecasting and potentially biases your final model).</p>\n\n<p>I think a good starting model would encompass:</p>\n\n<ul>\n<li>By Depot_ID</li>\n<li>By normalized + aggregated type of product (pasta weight in grams, breakfast chocolate in grams, etc.)</li>\n<li>By exploiting the potential of forecasting the initial stock for the first week (the latter could have a very large impact on the model)</li>\n</ul>\n\n<p>i.e better work on the products first than working on forecasting straight away. A good product dictionary should blow up a best dumb model by far in the experiences I had in forecasting stock in businesses. However, overfitting is a serious issue here due to the time size. Just looking at the data and testing some &quot;dumb&quot; models, a model loss of an additional (+-)35% can hold true (like: last week -&gt; Public LB (Public LB is week N+1?) ), but the average should lower this variation by far enough. If you go pure mathematical methods (own customized ML methods), try to aim under a relative 35% error at least (same threshold of a dumb model) for each week. The error should average out under 35% error thanks to the highly demanded products. (Someone can verify the threshold of 35%? I used only 2.7M rows.)</p>\n\n<p>As typical for commodities provisioning, it is better to over-provision (one-sided loss: pick back products and re-sell their elements for money) than under-provision (two-sided loss: for the client and for the provider) the stock. Thus the RMSLE which <a href=\"https://www.kaggle.com/laurae2/grupo-bimbo-inventory-demand/rmsle-loss-spread/output\">punishes faster</a> under-provisioning (higher cost) than over-provisioning (lower cost).</p>\n\n<p>Those who use xgboost (or any method which can change the loss function): don't forget to set the loss function accordingly (and to cap the lower tail which makes the gradient <em>explode</em>).</p>\n\n<p><img src=\"https://www.kaggle.com/blobs/download/forum-message-attachment-files/4405/Overview.JPG\" alt=\"Overview\" title></p>\n\n<p><img src=\"https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot001.png\" alt=\"enter image description here\" title></p>\n\n<p><img src=\"https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot002.png\" alt=\"enter image description here\" title></p>",
      "rawMarkdown": "(look at the bottom of this post for the picture overview)\r\n\r\n*N.B: still pending: returns next week interpretation.*\r\n\r\nUsed only Sales_Depot_ID < 1120 (2.7M rows) to understand how the data is structured, in addition to the instructions provided in the Data page. A picture is better than a thousand words here. I might be wrong on some parts (and there are parts I am guessing what is missing), I just made it very quickly to get an overview. I used simple knowledge from Accounting Management for this (it seems to be a very simple task, except you have Products showing up out of nowhere you must take care of). Some products are interchangeable just by a multiplier.\r\n\r\nAs the returns is delayed by 1 week (obvious and typically normal for that), it is not practical to use the first week as training. Either you lag everything by 1 week (which is feasible but you'd still lose 1 week in training), either you find a way to incorporate N-1 information in the first week which is not provided (which requires forecasting and potentially biases your final model).\r\n\r\nI think a good starting model would encompass:\r\n\r\n* By Depot_ID\r\n* By normalized + aggregated type of product (pasta weight in grams, breakfast chocolate in grams, etc.)\r\n* By exploiting the potential of forecasting the initial stock for the first week (the latter could have a very large impact on the model)\r\n\r\ni.e better work on the products first than working on forecasting straight away. A good product dictionary should blow up a best dumb model by far in the experiences I had in forecasting stock in businesses. However, overfitting is a serious issue here due to the time size. Just looking at the data and testing some \"dumb\" models, a model loss of an additional (+-)35% can hold true (like: last week -> Public LB (Public LB is week N+1?) ), but the average should lower this variation by far enough. If you go pure mathematical methods (own customized ML methods), try to aim under a relative 35% error at least (same threshold of a dumb model) for each week. The error should average out under 35% error thanks to the highly demanded products. (Someone can verify the threshold of 35%? I used only 2.7M rows.)\r\n\r\nAs typical for commodities provisioning, it is better to over-provision (one-sided loss: pick back products and re-sell their elements for money) than under-provision (two-sided loss: for the client and for the provider) the stock. Thus the RMSLE which [punishes faster][1] under-provisioning (higher cost) than over-provisioning (lower cost).\r\n\r\nThose who use xgboost (or any method which can change the loss function): don't forget to set the loss function accordingly (and to cap the lower tail which makes the gradient *explode*).\r\n\r\n![Overview][2]\r\n\r\n![enter image description here][3]\r\n\r\n![enter image description here][4]\r\n\r\n\r\n  [1]: https://www.kaggle.com/laurae2/grupo-bimbo-inventory-demand/rmsle-loss-spread/output\r\n  [2]: https://www.kaggle.com/blobs/download/forum-message-attachment-files/4405/Overview.JPG\r\n  [3]: https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot001.png\r\n  [4]: https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot002.png",
      "votes": null
    },
    {
      "id": "123601",
      "postDate": "06/13/2016 02:49:27",
      "content": "<p>Re. use the first week as training, I think we can use it since the the training data actually starts with week3. </p>",
      "rawMarkdown": "Re. use the first week as training, I think we can use it since the the training data actually starts with week3.",
      "votes": null
    },
    {
      "id": "123642",
      "postDate": "06/13/2016 08:22:49",
      "content": "<p>Laurae, I am not sure that I can follow your interpretation.  Almost all of the  <code>2,477,441</code> records with <code>Dev_uni_proxima &gt;0</code>  have </p>\n\n<pre><code>ifelse(Venta_uni_hoy- Dev_uni_proxima &lt; 0, 0, Venta_uni_hoy- Dev_uni_proxima) == Demanda_uni_equil\n</code></pre>\n\n<p>with the exception of  <code>1,953</code> records  (<code>0.07883134</code> percent!) </p>\n\n<p>So these figures strongly suggest that this is a demand estimate that was made <em>after</em> these products were returned: the demand forecasts made in week X to forecast week X+1</p>",
      "rawMarkdown": "Laurae, I am not sure that I can follow your interpretation.  Almost all of the  `2,477,441` records with `Dev_uni_proxima >0`  have \r\n\r\n    ifelse(Venta_uni_hoy- Dev_uni_proxima < 0, 0, Venta_uni_hoy- Dev_uni_proxima) == Demanda_uni_equil\r\n\r\nwith the exception of  `1,953` records  (`0.07883134` percent!) \r\n\r\nSo these figures strongly suggest that this is a demand estimate that was made _after_ these products were returned: the demand forecasts made in week X to forecast week X+1",
      "votes": null
    },
    {
      "id": "123658",
      "postDate": "06/13/2016 10:41:14",
      "content": "<p>[quote=MrOoijer;123642]</p>\n\n<p>So these figures strongly suggest that this is a demand estimate that was made <em>after</em> these products were returned: the demand forecasts made in week X to forecast week X+1</p>\n\n<p>[/quote]</p>\n\n<p>That's what I thought too when looking at the first time at the data (r2=0.995, obviously not available in the test set). However, in the Data section they say: <em>&quot;The demand for a product in a certain week is defined as the sales this week subtracted by the return next week.&quot;</em></p>\n\n<p>So, if I understand correctly, Dev_uni_proxima is used as a N+1 value?</p>\n\n<p>Such as, for instance, on week 3: Adjusted demand of week 3 - Predicted return on week 3 (for the weeks 4+) instead of purely Adjusted demand of week 3?</p>\n\n<p>Also, I wonder how to look for the carried over weeks returns, not given the stock.</p>\n\n<p>To make sure my interpretation picture is clear, it goes the following way starting at Product:</p>\n\n<ul>\n<li>Final stock = Initial Stock + [Demand of previous week (value of N-1) - Returns of this week (value of N-1) - Sales of this week (value of N)]</li>\n<li>Final stock is used to forecast the demand [= Sales this week - Returns next week, not shown in the picture though] and the <em>adjusted</em> demand (have to find out how they calculate it?)</li>\n</ul>\n\n<p>I think the &quot;+&quot; might be confusing on &quot;returns&quot; in the picture also. I'll edit it accordingly. I'm also noticing the picture I uploaded is an old version...?! '-'''</p>\n\n<p>@MrOoijer: correct me again if I again said a wrong thing in this post.</p>",
      "rawMarkdown": "[quote=MrOoijer;123642]\r\n\r\nSo these figures strongly suggest that this is a demand estimate that was made _after_ these products were returned: the demand forecasts made in week X to forecast week X+1\r\n\r\n[/quote]\r\n\r\nThat's what I thought too when looking at the first time at the data (r2=0.995, obviously not available in the test set). However, in the Data section they say: *\"The demand for a product in a certain week is defined as the sales this week subtracted by the return next week.\"*\r\n\r\nSo, if I understand correctly, Dev_uni_proxima is used as a N+1 value?\r\n\r\nSuch as, for instance, on week 3: Adjusted demand of week 3 - Predicted return on week 3 (for the weeks 4+) instead of purely Adjusted demand of week 3?\r\n\r\nAlso, I wonder how to look for the carried over weeks returns, not given the stock.\r\n\r\nTo make sure my interpretation picture is clear, it goes the following way starting at Product:\r\n\r\n* Final stock = Initial Stock + [Demand of previous week (value of N-1) - Returns of this week (value of N-1) - Sales of this week (value of N)]\r\n* Final stock is used to forecast the demand [= Sales this week - Returns next week, not shown in the picture though] and the *adjusted* demand (have to find out how they calculate it?)\r\n\r\nI think the \"+\" might be confusing on \"returns\" in the picture also. I'll edit it accordingly. I'm also noticing the picture I uploaded is an old version...?! '-'''\r\n\r\n@MrOoijer: correct me again if I again said a wrong thing in this post.",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 123601,
      "author_name": "horizon7",
      "author_url": "",
      "post_date": "06/13/2016 02:49:27",
      "content": "<p>Re. use the first week as training, I think we can use it since the the training data actually starts with week3. </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 123642,
      "author_name": "mrooijer",
      "author_url": "",
      "post_date": "06/13/2016 08:22:49",
      "content": "<p>Laurae, I am not sure that I can follow your interpretation.  Almost all of the  <code>2,477,441</code> records with <code>Dev_uni_proxima &gt;0</code>  have </p>\n\n<pre><code>ifelse(Venta_uni_hoy- Dev_uni_proxima &lt; 0, 0, Venta_uni_hoy- Dev_uni_proxima) == Demanda_uni_equil\n</code></pre>\n\n<p>with the exception of  <code>1,953</code> records  (<code>0.07883134</code> percent!) </p>\n\n<p>So these figures strongly suggest that this is a demand estimate that was made <em>after</em> these products were returned: the demand forecasts made in week X to forecast week X+1</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 123658,
      "author_name": "laurae2",
      "author_url": "",
      "post_date": "06/13/2016 10:41:14",
      "content": "<p>[quote=MrOoijer;123642]</p>\n\n<p>So these figures strongly suggest that this is a demand estimate that was made <em>after</em> these products were returned: the demand forecasts made in week X to forecast week X+1</p>\n\n<p>[/quote]</p>\n\n<p>That's what I thought too when looking at the first time at the data (r2=0.995, obviously not available in the test set). However, in the Data section they say: <em>&quot;The demand for a product in a certain week is defined as the sales this week subtracted by the return next week.&quot;</em></p>\n\n<p>So, if I understand correctly, Dev_uni_proxima is used as a N+1 value?</p>\n\n<p>Such as, for instance, on week 3: Adjusted demand of week 3 - Predicted return on week 3 (for the weeks 4+) instead of purely Adjusted demand of week 3?</p>\n\n<p>Also, I wonder how to look for the carried over weeks returns, not given the stock.</p>\n\n<p>To make sure my interpretation picture is clear, it goes the following way starting at Product:</p>\n\n<ul>\n<li>Final stock = Initial Stock + [Demand of previous week (value of N-1) - Returns of this week (value of N-1) - Sales of this week (value of N)]</li>\n<li>Final stock is used to forecast the demand [= Sales this week - Returns next week, not shown in the picture though] and the <em>adjusted</em> demand (have to find out how they calculate it?)</li>\n</ul>\n\n<p>I think the &quot;+&quot; might be confusing on &quot;returns&quot; in the picture also. I'll edit it accordingly. I'm also noticing the picture I uploaded is an old version...?! '-'''</p>\n\n<p>@MrOoijer: correct me again if I again said a wrong thing in this post.</p>",
      "votes": null,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "123516": "(look at the bottom of this post for the picture overview)\r\n\r\n*N.B: still pending: returns next week interpretation.*\r\n\r\nUsed only Sales_Depot_ID < 1120 (2.7M rows) to understand how the data is structured, in addition to the instructions provided in the Data page. A picture is better than a thousand words here. I might be wrong on some parts (and there are parts I am guessing what is missing), I just made it very quickly to get an overview. I used simple knowledge from Accounting Management for this (it seems to be a very simple task, except you have Products showing up out of nowhere you must take care of). Some products are interchangeable just by a multiplier.\r\n\r\nAs the returns is delayed by 1 week (obvious and typically normal for that), it is not practical to use the first week as training. Either you lag everything by 1 week (which is feasible but you'd still lose 1 week in training), either you find a way to incorporate N-1 information in the first week which is not provided (which requires forecasting and potentially biases your final model).\r\n\r\nI think a good starting model would encompass:\r\n\r\n* By Depot_ID\r\n* By normalized + aggregated type of product (pasta weight in grams, breakfast chocolate in grams, etc.)\r\n* By exploiting the potential of forecasting the initial stock for the first week (the latter could have a very large impact on the model)\r\n\r\ni.e better work on the products first than working on forecasting straight away. A good product dictionary should blow up a best dumb model by far in the experiences I had in forecasting stock in businesses. However, overfitting is a serious issue here due to the time size. Just looking at the data and testing some \"dumb\" models, a model loss of an additional (+-)35% can hold true (like: last week -> Public LB (Public LB is week N+1?) ), but the average should lower this variation by far enough. If you go pure mathematical methods (own customized ML methods), try to aim under a relative 35% error at least (same threshold of a dumb model) for each week. The error should average out under 35% error thanks to the highly demanded products. (Someone can verify the threshold of 35%? I used only 2.7M rows.)\r\n\r\nAs typical for commodities provisioning, it is better to over-provision (one-sided loss: pick back products and re-sell their elements for money) than under-provision (two-sided loss: for the client and for the provider) the stock. Thus the RMSLE which [punishes faster][1] under-provisioning (higher cost) than over-provisioning (lower cost).\r\n\r\nThose who use xgboost (or any method which can change the loss function): don't forget to set the loss function accordingly (and to cap the lower tail which makes the gradient *explode*).\r\n\r\n![Overview][2]\r\n\r\n![enter image description here][3]\r\n\r\n![enter image description here][4]\r\n\r\n\r\n  [1]: https://www.kaggle.com/laurae2/grupo-bimbo-inventory-demand/rmsle-loss-spread/output\r\n  [2]: https://www.kaggle.com/blobs/download/forum-message-attachment-files/4405/Overview.JPG\r\n  [3]: https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot001.png\r\n  [4]: https://www.kaggle.io/svf/263543/6fe217db54b5279358d04b36a1f5db85/Rplot002.png",
    "123601": "Re. use the first week as training, I think we can use it since the the training data actually starts with week3.",
    "123642": "Laurae, I am not sure that I can follow your interpretation.  Almost all of the  `2,477,441` records with `Dev_uni_proxima >0`  have \r\n\r\n    ifelse(Venta_uni_hoy- Dev_uni_proxima < 0, 0, Venta_uni_hoy- Dev_uni_proxima) == Demanda_uni_equil\r\n\r\nwith the exception of  `1,953` records  (`0.07883134` percent!) \r\n\r\nSo these figures strongly suggest that this is a demand estimate that was made _after_ these products were returned: the demand forecasts made in week X to forecast week X+1",
    "123658": "[quote=MrOoijer;123642]\r\n\r\nSo these figures strongly suggest that this is a demand estimate that was made _after_ these products were returned: the demand forecasts made in week X to forecast week X+1\r\n\r\n[/quote]\r\n\r\nThat's what I thought too when looking at the first time at the data (r2=0.995, obviously not available in the test set). However, in the Data section they say: *\"The demand for a product in a certain week is defined as the sales this week subtracted by the return next week.\"*\r\n\r\nSo, if I understand correctly, Dev_uni_proxima is used as a N+1 value?\r\n\r\nSuch as, for instance, on week 3: Adjusted demand of week 3 - Predicted return on week 3 (for the weeks 4+) instead of purely Adjusted demand of week 3?\r\n\r\nAlso, I wonder how to look for the carried over weeks returns, not given the stock.\r\n\r\nTo make sure my interpretation picture is clear, it goes the following way starting at Product:\r\n\r\n* Final stock = Initial Stock + [Demand of previous week (value of N-1) - Returns of this week (value of N-1) - Sales of this week (value of N)]\r\n* Final stock is used to forecast the demand [= Sales this week - Returns next week, not shown in the picture though] and the *adjusted* demand (have to find out how they calculate it?)\r\n\r\nI think the \"+\" might be confusing on \"returns\" in the picture also. I'll edit it accordingly. I'm also noticing the picture I uploaded is an old version...?! '-'''\r\n\r\n@MrOoijer: correct me again if I again said a wrong thing in this post."
  },
  "source": "meta"
}