Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions configs/weekly/xgboost_regression.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
{
"INCLUDE": ["../common/xgboost.json"],
"PARAMETERS_SETS": {
"xgboost data": [
{
"data": {
"source": "make_regression",
"generation_kwargs": [
{
"n_samples": 2097152, "n_features": 256
},
{
"n_samples": 2097152, "n_features": 32
}
],
"split_kwargs": { "train_size": 0.5, "test_size": 0.5 }
},
"algorithm": {
"estimator_params": [
{
"n_estimators": 128,
"max_depth": 8
Comment on lines +21 to +22
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these parameters make sense without reducing the learning rate? I guess in this case it'd be a toy problem with very high predicatibility, but would the tree structure end up being similar as what you'd get for the original epsilon data?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for misunderstanding.

this is not the replacement for epsion. This is the toy case I have used for EMR vs GNR performance comparison. We need to have this case in some public benchmarks to be able to share it.

},
{
"n_estimators": 128,
"max_depth": 3
},
{
"n_estimators": 32,
"max_depth": 8
},
{
"n_estimators": 32,
"max_depth": 3
}
]
}
}
]
},
"TEMPLATES": {
"regression": {
"SETS": [
"xgboost regression",
"xgboost implementations",
"xgboost data"
]
}
}
}
Loading