-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hyperparameter importance chart #54
Conversation
0bd00ad
to
c4c2c4a
Compare
Wow, great! I'll review tomorrow.
I completely agree with your decision. It is quite difficult to port an importance evaluator into TypeScript because fANOVA evaluator requires the random forest regression model. |
Co-authored-by: Masashi Shibata <[email protected]>
Co-authored-by: Masashi Shibata <[email protected]>
Co-authored-by: Masashi Shibata <[email protected]>
b0b13ad
to
64ddb45
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good and easy to read! I left some minor suggestions.
optuna_dashboard/static/components/HyperparameterImportances.tsx
Outdated
Show resolved
Hide resolved
plotParamImportances(paramsImportanceData) | ||
} | ||
fetchAndPlotParamImportances(studyId) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
param-importance.mp4
Please set deps
to avoid sending API requests at every render.
}) | |
}, [studyId]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh thanks! I missed that part, re-rendering could be unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just thinking sometimes studyId
could not be a proper dependency as trials may get updated while the studyId
remains the same while parameter importance requires a re-evaluation.
Co-authored-by: Masashi Shibata <[email protected]>
Co-authored-by: Masashi Shibata <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!! For further improvements, we can work on following tasks in another pull requests:
- In-memory cache:
get_param_importances()
is computationally expensive because of the training of RandomForest model. So it's better to cache the result at server-side liketrials
are cached. - Multi-objective support:
It seems that Optuna's importance module does not still support multi-objective study. So we need to send a pull request to Optuna for this.It seems to be supported. - Calculate hyperparameter importances on Web Assembly: After I implement RandomForest and fANOVA algorithm in Goptuna, we can calculate hyperparameter importances at WebAssembly. It's a bit technically difficult, but interesting.
Contributor License Agreement
This repository (
optuna-dashboard
) and Goptuna share common code.This pull request may therefore be ported to Goptuna.
Make sure that you understand the consequences concerning licenses and check the box below if you accept the term before creating this pull request.
Reference Issues/PRs
Fixs #25
Add hyperparameter importance chart
There're two ways to add hyperparameter importance chart. One is to implement the evaluator which completely mirrors the one used by optuna via typescript and another is to use the optuna
optuna.importance.get_param_importances
API directly.The former makes the logic cleaner but involves extra computation in the browser, and implementing a complete parameter importance function by ts requires an update whenever the optuna API changes.
The latter one is much more flexible and only requires introducing another API call. But the con is it takes longer for the server to get the importance result.
Here we take the second approach and only consider the single objective function case. For future multi-objective case, we can extend the API with query parameters representing params and target selected by the user.