Thanks to Andrey Ustyuzhanin, Alex Rogozhnikov et al., the authors/maintainers of hep_ml, for their effort.\nI have spent two evenings installing hep_ml, and three evenings running it, but I have obtained 0.991099 using just one model - UGradientBoostingClassifier <- zip file of my solution.
\n\nBecause I know neither R nor Python, the solution is written partly in R, partly in Python 2.7.
\n\nNew things regarding scripts known before the end of the competition:
\n\n-- new feature (Python file)\ndf['NEW_FD_LT']=df['FlightDistance']/df['LifeTime'] \nof the dimension of "velocity" ;)
\n\n-- removing some specific rows from evaluation file enables to obtain \nbetter evaluation close to that on LB or that (not allowed) min_ANNmuon>0.4 (R file).
\n\nNo mass "reconstruction".
", "messages": [ { "id": "96169", "postDate": "10/14/2015 23:20:32", "content": "Thanks to Andrey Ustyuzhanin, Alex Rogozhnikov et al., the authors/maintainers of hep_ml, for their effort.\nI have spent two evenings installing hep_ml, and three evenings running it, but I have obtained 0.991099 using just one model - UGradientBoostingClassifier <- zip file of my solution.
\n\nBecause I know neither R nor Python, the solution is written partly in R, partly in Python 2.7.
\n\nNew things regarding scripts known before the end of the competition:
\n\n-- new feature (Python file)\ndf['NEW_FD_LT']=df['FlightDistance']/df['LifeTime'] \nof the dimension of "velocity" ;)
\n\n-- removing some specific rows from evaluation file enables to obtain \nbetter evaluation close to that on LB or that (not allowed) min_ANNmuon>0.4 (R file).
\n\nNo mass "reconstruction".
", "rawMarkdown": "Thanks to Andrey Ustyuzhanin, Alex Rogozhnikov et al., the authors/maintainers of hep_ml, for their effort.\r\nI have spent two evenings installing hep_ml, and three evenings running it, but I have obtained **0.991099** using just one model - [UGradientBoostingClassifier][1] <- zip file of my solution. \r\n\r\nBecause I know neither R nor Python, the solution is written partly in R, partly in Python 2.7.\r\n\r\nNew things regarding scripts known before the end of the competition:\r\n\r\n-- new feature (Python file)\r\ndf['NEW_FD_LT']=df['FlightDistance']/df['LifeTime'] \r\nof the dimension of \"velocity\" ;)\r\n\r\n-- removing some specific rows from evaluation file enables to obtain \r\nbetter evaluation close to that on LB or that (not allowed) min_ANNmuon>0.4 (R file). \r\n\r\nNo mass \"reconstruction\".\r\n\r\n [1]: http://grzegorz.sionkowski.pl/zip/justUGBC.zip", "votes": null }, { "id": "96179", "postDate": "10/15/2015 00:33:05", "content": "Hi Grzegorz,
\n\nThis is an impressive result, given that you used only one model!\nBy the way, how did you tune it?
", "rawMarkdown": "Hi Grzegorz,\r\n\r\nThis is an impressive result, given that you used only one model!\r\nBy the way, how did you tune it?", "votes": null }, { "id": "96188", "postDate": "10/15/2015 00:57:58", "content": "Anton,
\n\nUGBC does something good with background ;), so I thought, that "normal" part of train taken for evaluation of existence of other phenomenon shows "too good" results because of these zeros (background). That is why I decided to remove some 0s. Looking at histograms I made a cut at IPSig=5 and VertexChi2=4 taking the regions of high signal to background ratio (analogy to evaluation basing on not allowed min_ANNmuon>0.4). Data selected in such manner work really good in AUC evaluation, so tuning was performed manually by ~10 steps, going up and down with 2-3 parameters of UGBC and looking at this evaluation value.
", "rawMarkdown": "Anton, \r\n\r\nUGBC does something good with background ;), so I thought, that \"normal\" part of train taken for evaluation of existence of other phenomenon shows \"too good\" results because of these zeros (background). That is why I decided to remove some 0s. Looking at [histograms][1] I made a cut at IPSig=5 and VertexChi2=4 taking the regions of high signal to background ratio (analogy to evaluation basing on not allowed min_ANNmuon>0.4). Data selected in such manner work really good in AUC evaluation, so tuning was performed manually by ~10 steps, going up and down with 2-3 parameters of UGBC and looking at this evaluation value.\r\n\r\n\r\n [1]: https://www.kaggle.com/gramolin/flavours-of-physics/histograms", "votes": null }, { "id": "96242", "postDate": "10/15/2015 08:00:11", "content": "yes, indeed an impressive result -- congratulations and thanks for sharing the methodology !
", "rawMarkdown": "yes, indeed an impressive result -- congratulations and thanks for sharing the methodology !", "votes": null }, { "id": "96401", "postDate": "10/16/2015 06:44:34", "content": "I (like probably many others) spent a lot of time doing wrong things.
\n\nIn my case, I thought, that the aim is to train model on one decay, check the agreement on another decay and if it is passed, it means that model is (probably) generally good to find any other decay.
\n\nNow I see that to let me discover such a model in my way, the organizers should give us not one, but two or more test files. One (or more) to check agreement, one to find the decay. But they mixed them all in one. \nMy final model (nothing special, just using UGBC) was created when I surrendered.
\n\nNext time I will read the rules until I feel pain between my ears ;)
", "rawMarkdown": "I (like probably many others) spent a lot of time doing wrong things. \r\n\r\nIn my case, I thought, that the aim is to train model on one decay, check the agreement on another decay and if it is passed, it means that model is (probably) generally good to find any other decay. \r\n\r\nNow I see that to let me discover such a model in my way, the organizers should give us not one, but two or more test files. One (or more) to check agreement, one to find the decay. But they mixed them all in one. \r\nMy final model (nothing special, just using UGBC) was created when I surrendered.\r\n\r\nNext time I will read the rules until I feel pain between my ears ;)", "votes": null }, { "id": "96402", "postDate": "10/16/2015 08:04:13", "content": "From a ML perspective, testing on distribution B different from training distribution A makes little sense and provides little guarantees if your goal is model for A (not for B). On the other hand, if data set B (control channel) was considered more reliable than A and goal was to find more general model, then, in my humble opinion (I am not a physicist), the organizers should propose training on both data sets. Or even training solely on B and subsequently transfer model to A.
", "rawMarkdown": "From a ML perspective, testing on distribution B different from training distribution A makes little sense and provides little guarantees if your goal is model for A (not for B). On the other hand, if data set B (control channel) was considered more reliable than A and goal was to find more general model, then, in my humble opinion (I am not a physicist), the organizers should propose training on both data sets. Or even training solely on B and subsequently transfer model to A.", "votes": null }, { "id": "96416", "postDate": "10/16/2015 12:59:33", "content": "I have uploaded simplified (without evaluating) version of my script: Kaggle-UGBC-GS-simplified
\n\n*original: 80% training.csv, fl_coefficient=5, n_estimators=750, LB=0.992031
\n\n*simplified: 100% training.csv, fl_coefficient=15, n_estimators=550, LB=0.992632
\n\nFeel free to change the parameters or add new features to go up to TOP 10.
", "rawMarkdown": "I have uploaded simplified (without evaluating) version of my script: [Kaggle-UGBC-GS-simplified][1]\r\n\r\n*original: 80% training.csv, fl_coefficient=5, n_estimators=750, LB=0.992031\r\n\r\n*simplified: 100% training.csv, fl_coefficient=15, n_estimators=550, LB=0.992632\r\n\r\nFeel free to change the parameters or add new features to go up to TOP 10.\r\n\r\n\r\n\r\n\r\n [1]: https://www.kaggle.com/sionek/flavours-of-physics/ugbc-gs2", "votes": null }, { "id": "96431", "postDate": "10/16/2015 15:49:58", "content": "As someone mentioned here on the board, "undertraining" helps a lot to pass the submission tests.\nAccording to my local CV, which turned out to be very close to final results, my best UGBC produced a score 0.993887. But again, it did not pass the cvm test and I was not really enthusiastic to "tune it down".
", "rawMarkdown": "As someone mentioned here on the board, \"undertraining\" helps a lot to pass the submission tests.\r\nAccording to my local CV, which turned out to be very close to final results, my best UGBC produced a score 0.993887. But again, it did not pass the cvm test and I was not really enthusiastic to \"tune it down\".", "votes": null }, { "id": "96443", "postDate": "10/16/2015 17:50:15", "content": "I do not know how many Kagglers knew that they had to create a model that should detect two different decays in one experiment. I'm not sure if all the boys and girls from CERN were aware of it.
\n\nProbably that is why undertraining, spoiling a model being good to detect one isolated decay gives better results than its further improvement.
", "rawMarkdown": "I do not know how many Kagglers knew that they had to create a model that should detect two different decays in one experiment. I'm not sure if all the boys and girls from CERN were aware of it. \r\n\r\nProbably that is why undertraining, spoiling a model being good to detect one isolated decay gives better results than its further improvement.", "votes": null }, { "id": "96458", "postDate": "10/16/2015 20:37:41", "content": "I think 'undertrain' makes the model more generalized for tolerating two types of particle decays (tau from signal and Ds from control). Removing some training data may help, and there are other tricks to 'weaken' the model, like a large learning rate and/or a large min child weight for xgboost, bucketizing some features etc. I will post something about my experiment of weakening the models.
\n\nP.S. I didn't know UGBC was a nice classifier and I didn't figure out the grid search interface (about adding ['mass'] in grid search interface), plus UGBC was single thread and too slow, otherwise my score would be much nicer.
", "rawMarkdown": "I think 'undertrain' makes the model more generalized for tolerating two types of particle decays (tau from signal and Ds from control). Removing some training data may help, and there are other tricks to 'weaken' the model, like a large learning rate and/or a large min child weight for xgboost, bucketizing some features etc. I will post something about my experiment of weakening the models.\r\n\r\nP.S. I didn't know UGBC was a nice classifier and I didn't figure out the grid search interface (about adding ['mass'] in grid search interface), plus UGBC was single thread and too slow, otherwise my score would be much nicer.", "votes": null }, { "id": "96459", "postDate": "10/16/2015 21:01:44", "content": "Agree, XGBoost is so accurate and fast that it makes it very unappealing to use other boosting algorithms instead. Tuning UGBC drove me crazy.
", "rawMarkdown": "Agree, XGBoost is so accurate and fast that it makes it very unappealing to use other boosting algorithms instead. Tuning UGBC drove me crazy.", "votes": null }, { "id": "96461", "postDate": "10/16/2015 21:03:47", "content": "Undertraining acts like regularizer, and is similar to early stopping in neural nets. But the goal of reularization is to avoid ovrfitting to training data and achieve good performance on test data from the same distribution. Here we make sure that model works on data from another distribution it was not trained on and is not intended for in future use. I think this knowledge does not provide theoretical guarantee for performance on original data.
", "rawMarkdown": "Undertraining acts like regularizer, and is similar to early stopping in neural nets. But the goal of reularization is to avoid ovrfitting to training data and achieve good performance on test data *from the same distribution*. Here we make sure that model works on data from another distribution it was not trained on and is not intended for in future use. I think this knowledge does not provide theoretical guarantee for performance on original data.", "votes": null }, { "id": "96478", "postDate": "10/17/2015 03:41:05", "content": "Nice Code. I could get upto 0.983815 using average of 3 UGBC with similar parameters. The code is here.
", "rawMarkdown": "Nice Code. I could get upto 0.983815 using average of 3 UGBC with similar parameters. The code is [here][1]. \r\n\r\n\r\n [1]: https://www.kaggle.com/kumareshd/flavours-of-physics/keras-best-finding", "votes": null }, { "id": "96484", "postDate": "10/17/2015 07:41:33", "content": "Anton, Andre, rakhlin, phunter, Kumaresh, Thank you very much for discussion in this thread and good luck in next competitions.
", "rawMarkdown": "Anton, Andre, rakhlin, phunter, Kumaresh, Thank you very much for discussion in this thread and good luck in next competitions.", "votes": null }, { "id": "96506", "postDate": "10/17/2015 17:41:12", "content": "Thank you for your code and particularly for the new features, Grzegorz. See you in next competitions.
", "rawMarkdown": "Thank you for your code and particularly for the new features, Grzegorz. See you in next competitions.", "votes": null }, { "id": "96510", "postDate": "10/17/2015 19:00:10", "content": "Thanks everyone for sharing your ideas and codes. It really helps a lot .
", "rawMarkdown": "Thanks everyone for sharing your ideas and codes. It really helps a lot .", "votes": null }, { "id": "96607", "postDate": "10/19/2015 03:52:43", "content": "@Anton Laptiev I just opened an issue on xgboost github for integrating BinFlatnessLossFunction in xgboost , and @tianqi answered that xgboost could be readily supporting a customized loss function using other columns of data. The issue is here https://github.com/dmlc/xgboost/issues/550 if some people are interested, please check it out. It can help HEP in real life.
", "rawMarkdown": "Anton Laptiev I just opened an issue on xgboost github for integrating BinFlatnessLossFunction in xgboost , and @tianqi answered that xgboost could be readily supporting a customized loss function using other columns of data. The issue is here https://github.com/dmlc/xgboost/issues/550 if some people are interested, please check it out. It can help HEP in real life.", "votes": null } ], "comments": [ { "id": 96179, "author_name": "anton79", "author_url": "", "post_date": "10/15/2015 00:33:05", "content": "Hi Grzegorz,
\n\nThis is an impressive result, given that you used only one model!\nBy the way, how did you tune it?
", "votes": null, "replies": [] }, { "id": 96188, "author_name": "sionek", "author_url": "", "post_date": "10/15/2015 00:57:58", "content": "Anton,
\n\nUGBC does something good with background ;), so I thought, that "normal" part of train taken for evaluation of existence of other phenomenon shows "too good" results because of these zeros (background). That is why I decided to remove some 0s. Looking at histograms I made a cut at IPSig=5 and VertexChi2=4 taking the regions of high signal to background ratio (analogy to evaluation basing on not allowed min_ANNmuon>0.4). Data selected in such manner work really good in AUC evaluation, so tuning was performed manually by ~10 steps, going up and down with 2-3 parameters of UGBC and looking at this evaluation value.
", "votes": null, "replies": [] }, { "id": 96242, "author_name": "holzner", "author_url": "", "post_date": "10/15/2015 08:00:11", "content": "yes, indeed an impressive result -- congratulations and thanks for sharing the methodology !
", "votes": null, "replies": [] }, { "id": 96401, "author_name": "sionek", "author_url": "", "post_date": "10/16/2015 06:44:34", "content": "I (like probably many others) spent a lot of time doing wrong things.
\n\nIn my case, I thought, that the aim is to train model on one decay, check the agreement on another decay and if it is passed, it means that model is (probably) generally good to find any other decay.
\n\nNow I see that to let me discover such a model in my way, the organizers should give us not one, but two or more test files. One (or more) to check agreement, one to find the decay. But they mixed them all in one. \nMy final model (nothing special, just using UGBC) was created when I surrendered.
\n\nNext time I will read the rules until I feel pain between my ears ;)
", "votes": null, "replies": [] }, { "id": 96402, "author_name": "rakhlin", "author_url": "", "post_date": "10/16/2015 08:04:13", "content": "From a ML perspective, testing on distribution B different from training distribution A makes little sense and provides little guarantees if your goal is model for A (not for B). On the other hand, if data set B (control channel) was considered more reliable than A and goal was to find more general model, then, in my humble opinion (I am not a physicist), the organizers should propose training on both data sets. Or even training solely on B and subsequently transfer model to A.
", "votes": null, "replies": [] }, { "id": 96416, "author_name": "sionek", "author_url": "", "post_date": "10/16/2015 12:59:33", "content": "I have uploaded simplified (without evaluating) version of my script: Kaggle-UGBC-GS-simplified
\n\n*original: 80% training.csv, fl_coefficient=5, n_estimators=750, LB=0.992031
\n\n*simplified: 100% training.csv, fl_coefficient=15, n_estimators=550, LB=0.992632
\n\nFeel free to change the parameters or add new features to go up to TOP 10.
", "votes": null, "replies": [] }, { "id": 96431, "author_name": "anton79", "author_url": "", "post_date": "10/16/2015 15:49:58", "content": "As someone mentioned here on the board, "undertraining" helps a lot to pass the submission tests.\nAccording to my local CV, which turned out to be very close to final results, my best UGBC produced a score 0.993887. But again, it did not pass the cvm test and I was not really enthusiastic to "tune it down".
", "votes": null, "replies": [] }, { "id": 96443, "author_name": "sionek", "author_url": "", "post_date": "10/16/2015 17:50:15", "content": "I do not know how many Kagglers knew that they had to create a model that should detect two different decays in one experiment. I'm not sure if all the boys and girls from CERN were aware of it.
\n\nProbably that is why undertraining, spoiling a model being good to detect one isolated decay gives better results than its further improvement.
", "votes": null, "replies": [] }, { "id": 96458, "author_name": "phunter", "author_url": "", "post_date": "10/16/2015 20:37:41", "content": "I think 'undertrain' makes the model more generalized for tolerating two types of particle decays (tau from signal and Ds from control). Removing some training data may help, and there are other tricks to 'weaken' the model, like a large learning rate and/or a large min child weight for xgboost, bucketizing some features etc. I will post something about my experiment of weakening the models.
\n\nP.S. I didn't know UGBC was a nice classifier and I didn't figure out the grid search interface (about adding ['mass'] in grid search interface), plus UGBC was single thread and too slow, otherwise my score would be much nicer.
", "votes": null, "replies": [] }, { "id": 96459, "author_name": "anton79", "author_url": "", "post_date": "10/16/2015 21:01:44", "content": "Agree, XGBoost is so accurate and fast that it makes it very unappealing to use other boosting algorithms instead. Tuning UGBC drove me crazy.
", "votes": null, "replies": [] }, { "id": 96461, "author_name": "rakhlin", "author_url": "", "post_date": "10/16/2015 21:03:47", "content": "Undertraining acts like regularizer, and is similar to early stopping in neural nets. But the goal of reularization is to avoid ovrfitting to training data and achieve good performance on test data from the same distribution. Here we make sure that model works on data from another distribution it was not trained on and is not intended for in future use. I think this knowledge does not provide theoretical guarantee for performance on original data.
", "votes": null, "replies": [] }, { "id": 96478, "author_name": "kumareshd", "author_url": "", "post_date": "10/17/2015 03:41:05", "content": "Nice Code. I could get upto 0.983815 using average of 3 UGBC with similar parameters. The code is here.
", "votes": null, "replies": [] }, { "id": 96484, "author_name": "sionek", "author_url": "", "post_date": "10/17/2015 07:41:33", "content": "Anton, Andre, rakhlin, phunter, Kumaresh, Thank you very much for discussion in this thread and good luck in next competitions.
", "votes": null, "replies": [] }, { "id": 96506, "author_name": "rakhlin", "author_url": "", "post_date": "10/17/2015 17:41:12", "content": "Thank you for your code and particularly for the new features, Grzegorz. See you in next competitions.
", "votes": null, "replies": [] }, { "id": 96510, "author_name": "pythonomic", "author_url": "", "post_date": "10/17/2015 19:00:10", "content": "Thanks everyone for sharing your ideas and codes. It really helps a lot .
", "votes": null, "replies": [] }, { "id": 96607, "author_name": "phunter", "author_url": "", "post_date": "10/19/2015 03:52:43", "content": "@Anton Laptiev I just opened an issue on xgboost github for integrating BinFlatnessLossFunction in xgboost , and @tianqi answered that xgboost could be readily supporting a customized loss function using other columns of data. The issue is here https://github.com/dmlc/xgboost/issues/550 if some people are interested, please check it out. It can help HEP in real life.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "96169": "Thanks to Andrey Ustyuzhanin, Alex Rogozhnikov et al., the authors/maintainers of hep_ml, for their effort.\r\nI have spent two evenings installing hep_ml, and three evenings running it, but I have obtained **0.991099** using just one model - [UGradientBoostingClassifier][1] <- zip file of my solution. \r\n\r\nBecause I know neither R nor Python, the solution is written partly in R, partly in Python 2.7.\r\n\r\nNew things regarding scripts known before the end of the competition:\r\n\r\n-- new feature (Python file)\r\ndf['NEW_FD_LT']=df['FlightDistance']/df['LifeTime'] \r\nof the dimension of \"velocity\" ;)\r\n\r\n-- removing some specific rows from evaluation file enables to obtain \r\nbetter evaluation close to that on LB or that (not allowed) min_ANNmuon>0.4 (R file). \r\n\r\nNo mass \"reconstruction\".\r\n\r\n [1]: http://grzegorz.sionkowski.pl/zip/justUGBC.zip", "96179": "Hi Grzegorz,\r\n\r\nThis is an impressive result, given that you used only one model!\r\nBy the way, how did you tune it?", "96188": "Anton, \r\n\r\nUGBC does something good with background ;), so I thought, that \"normal\" part of train taken for evaluation of existence of other phenomenon shows \"too good\" results because of these zeros (background). That is why I decided to remove some 0s. Looking at [histograms][1] I made a cut at IPSig=5 and VertexChi2=4 taking the regions of high signal to background ratio (analogy to evaluation basing on not allowed min_ANNmuon>0.4). Data selected in such manner work really good in AUC evaluation, so tuning was performed manually by ~10 steps, going up and down with 2-3 parameters of UGBC and looking at this evaluation value.\r\n\r\n\r\n [1]: https://www.kaggle.com/gramolin/flavours-of-physics/histograms", "96242": "yes, indeed an impressive result -- congratulations and thanks for sharing the methodology !", "96401": "I (like probably many others) spent a lot of time doing wrong things. \r\n\r\nIn my case, I thought, that the aim is to train model on one decay, check the agreement on another decay and if it is passed, it means that model is (probably) generally good to find any other decay. \r\n\r\nNow I see that to let me discover such a model in my way, the organizers should give us not one, but two or more test files. One (or more) to check agreement, one to find the decay. But they mixed them all in one. \r\nMy final model (nothing special, just using UGBC) was created when I surrendered.\r\n\r\nNext time I will read the rules until I feel pain between my ears ;)", "96402": "From a ML perspective, testing on distribution B different from training distribution A makes little sense and provides little guarantees if your goal is model for A (not for B). On the other hand, if data set B (control channel) was considered more reliable than A and goal was to find more general model, then, in my humble opinion (I am not a physicist), the organizers should propose training on both data sets. Or even training solely on B and subsequently transfer model to A.", "96416": "I have uploaded simplified (without evaluating) version of my script: [Kaggle-UGBC-GS-simplified][1]\r\n\r\n*original: 80% training.csv, fl_coefficient=5, n_estimators=750, LB=0.992031\r\n\r\n*simplified: 100% training.csv, fl_coefficient=15, n_estimators=550, LB=0.992632\r\n\r\nFeel free to change the parameters or add new features to go up to TOP 10.\r\n\r\n\r\n\r\n\r\n [1]: https://www.kaggle.com/sionek/flavours-of-physics/ugbc-gs2", "96431": "As someone mentioned here on the board, \"undertraining\" helps a lot to pass the submission tests.\r\nAccording to my local CV, which turned out to be very close to final results, my best UGBC produced a score 0.993887. But again, it did not pass the cvm test and I was not really enthusiastic to \"tune it down\".", "96443": "I do not know how many Kagglers knew that they had to create a model that should detect two different decays in one experiment. I'm not sure if all the boys and girls from CERN were aware of it. \r\n\r\nProbably that is why undertraining, spoiling a model being good to detect one isolated decay gives better results than its further improvement.", "96458": "I think 'undertrain' makes the model more generalized for tolerating two types of particle decays (tau from signal and Ds from control). Removing some training data may help, and there are other tricks to 'weaken' the model, like a large learning rate and/or a large min child weight for xgboost, bucketizing some features etc. I will post something about my experiment of weakening the models.\r\n\r\nP.S. I didn't know UGBC was a nice classifier and I didn't figure out the grid search interface (about adding ['mass'] in grid search interface), plus UGBC was single thread and too slow, otherwise my score would be much nicer.", "96459": "Agree, XGBoost is so accurate and fast that it makes it very unappealing to use other boosting algorithms instead. Tuning UGBC drove me crazy.", "96461": "Undertraining acts like regularizer, and is similar to early stopping in neural nets. But the goal of reularization is to avoid ovrfitting to training data and achieve good performance on test data *from the same distribution*. Here we make sure that model works on data from another distribution it was not trained on and is not intended for in future use. I think this knowledge does not provide theoretical guarantee for performance on original data.", "96478": "Nice Code. I could get upto 0.983815 using average of 3 UGBC with similar parameters. The code is [here][1]. \r\n\r\n\r\n [1]: https://www.kaggle.com/kumareshd/flavours-of-physics/keras-best-finding", "96484": "Anton, Andre, rakhlin, phunter, Kumaresh, Thank you very much for discussion in this thread and good luck in next competitions.", "96506": "Thank you for your code and particularly for the new features, Grzegorz. See you in next competitions.", "96510": "Thanks everyone for sharing your ideas and codes. It really helps a lot .", "96607": "Anton Laptiev I just opened an issue on xgboost github for integrating BinFlatnessLossFunction in xgboost , and @tianqi answered that xgboost could be readily supporting a customized loss function using other columns of data. The issue is here https://github.com/dmlc/xgboost/issues/550 if some people are interested, please check it out. It can help HEP in real life." }, "source": "meta" }