![\"feature](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1779058%2Fd060917244af1de3d58937225661fe19%2F__results___7_2.png?generation=1571490861689596&alt=media\")
Hi everyone, \nin both train and test data we have building id and looks like the buildings in the train are the same as the ones in test. So one could build a per-building model for each building and/or use the building_id as a feature... am I wrong? Or does the competition require a per-meter-type model? It's not clear to me... or maybe am I just overthinking?\nThanks
", "messages": [ { "id": "652451", "postDate": "10/18/2019 21:29:08", "content": "Hi everyone, \nin both train and test data we have building id and looks like the buildings in the train are the same as the ones in test. So one could build a per-building model for each building and/or use the building_id as a feature... am I wrong? Or does the competition require a per-meter-type model? It's not clear to me... or maybe am I just overthinking?\nThanks
", "rawMarkdown": "Hi everyone, \nin both train and test data we have *building id* and looks like the buildings in the train are the same as the ones in test. So one could build a *per-building model* for each building and/or use the building_id as a feature... am I wrong? Or does the competition require a *per-meter-type model*? It's not clear to me... or maybe am I just overthinking?\nThanks", "votes": null }, { "id": "652456", "postDate": "10/18/2019 21:45:00", "content": "Since there are over 1000 buildings in the data set a per building model might make sense except for the compute cost - if you get a very big feature set your google cloud platform bill might get pretty big. So I think its a feature with lot of importance. Also the issue of train data for a building seldom seems to hit the full year hours that occur in the test.
\n\nHarder question for me is if a need exists for a per meter model - I am thinking that it does but using meter type only as feature in early days.
", "rawMarkdown": "Since there are over 1000 buildings in the data set a per building model might make sense except for the compute cost - if you get a very big feature set your google cloud platform bill might get pretty big. So I think its a feature with lot of importance. Also the issue of train data for a building seldom seems to hit the full year hours that occur in the test.\n\nHarder question for me is if a need exists for a per meter model - I am thinking that it does but using meter type only as feature in early days.", "votes": null }, { "id": "652829", "postDate": "10/19/2019 13:15:17", "content": "Seems for this competition it is , as we already have a fixed list of building id in building_metadata. Also as found in this kernel, its importance is pretty high.
Rather than per-building model, what about per-primary_use model? π
\n\nAlso in my model, building_id is the most significant.
", "rawMarkdown": "Rather than per-building model, what about per-primary_use model? π \n\nAlso in my model, building_id is the most significant.", "votes": null }, { "id": "660146", "postDate": "10/28/2019 18:53:51", "content": "And everybody do so - develop models where there is feature 'building id' - in fact, for the individual buildings. This is a mistake of the authors of the competition. If they wanted to get a versatile model, they had to ask for predictions for the 'square' of ββthe houses or 'year' they were built. And so the predictions are needed for the each buildings.
", "rawMarkdown": "And everybody do so - develop models where there is feature '*building id*' - in fact, for the individual buildings. This is a mistake of the authors of the competition. If they wanted to get a versatile model, they had to ask for predictions for the '*square*' of ββthe houses or '*year*' they were built. And so the predictions are needed for the each buildings.", "votes": null } ], "comments": [ { "id": 652456, "author_name": "pcjimmmy", "author_url": "", "post_date": "10/18/2019 21:45:00", "content": "Since there are over 1000 buildings in the data set a per building model might make sense except for the compute cost - if you get a very big feature set your google cloud platform bill might get pretty big. So I think its a feature with lot of importance. Also the issue of train data for a building seldom seems to hit the full year hours that occur in the test.
\n\nHarder question for me is if a need exists for a per meter model - I am thinking that it does but using meter type only as feature in early days.
", "votes": null, "replies": [] }, { "id": 652829, "author_name": "khairulislam", "author_url": "", "post_date": "10/19/2019 13:15:17", "content": "Seems for this competition it is , as we already have a fixed list of building id in building_metadata. Also as found in this kernel, its importance is pretty high.
Rather than per-building model, what about per-primary_use model? π
\n\nAlso in my model, building_id is the most significant.
", "votes": null, "replies": [] }, { "id": 660146, "author_name": "vbmokin", "author_url": "", "post_date": "10/28/2019 18:53:51", "content": "And everybody do so - develop models where there is feature 'building id' - in fact, for the individual buildings. This is a mistake of the authors of the competition. If they wanted to get a versatile model, they had to ask for predictions for the 'square' of ββthe houses or 'year' they were built. And so the predictions are needed for the each buildings.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "652451": "Hi everyone, \nin both train and test data we have *building id* and looks like the buildings in the train are the same as the ones in test. So one could build a *per-building model* for each building and/or use the building_id as a feature... am I wrong? Or does the competition require a *per-meter-type model*? It's not clear to me... or maybe am I just overthinking?\nThanks", "652456": "Since there are over 1000 buildings in the data set a per building model might make sense except for the compute cost - if you get a very big feature set your google cloud platform bill might get pretty big. So I think its a feature with lot of importance. Also the issue of train data for a building seldom seems to hit the full year hours that occur in the test.\n\nHarder question for me is if a need exists for a per meter model - I am thinking that it does but using meter type only as feature in early days.", "652829": "Seems for this competition it is , as we already have a fixed list of building id in building_metadata. Also as found in this [kernel](https://www.kaggle.com/divrikwicky/ashrae-lofo-feature-importance-on-best-pub-kernel), its importance is pretty high. ", "653380": "Rather than per-building model, what about per-primary_use model? π \n\nAlso in my model, building_id is the most significant.", "660146": "And everybody do so - develop models where there is feature '*building id*' - in fact, for the individual buildings. This is a mistake of the authors of the competition. If they wanted to get a versatile model, they had to ask for predictions for the '*square*' of ββthe houses or '*year*' they were built. And so the predictions are needed for the each buildings." }, "source": "meta" }