Benchmark gap encoder early stopping #681
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
Co-authored-by: Lilian <[email protected]>
|
@LilianBoulard Running with the same batch size, the speedup is smaller, but I think still useful. 
|
|
@LilianBoulard I think it's ready, WDYT? |
LeoGrin
added a commit
to LeoGrin/skrub
that referenced
this pull request
Aug 24, 2023
* benchmark * fix bug due to mixed type * verbose * test * fix bug * add benchmark results * add balenced accuracy * Update benchmarks/bench_gap_es_score.py Co-authored-by: Lilian <[email protected]> * remove prints * run with the same batch size * benchmark results with the same batch size --------- Co-authored-by: Lilian <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Benchmark to evaluate the early stopping change made in #680, compared to the previous version of the gap encoder.
Based on #663 by @simonamaggio and #593 by @LilianBoulard
Compared to #663 , we don't compute the full score regularly, as this operation is very slow. Instead, we use an exponentially weighted average of each batch score. This is based on sklearn's MinibatchNMF's code.
Results
It seems that the new version is faster, while the KL score and balanced accuracy don't change. I think the speed can be improved further by tuning hyperparameters, this is the subject of another benchmark in #680. Furthermore, id columns like
seqidtake a long time to fit even with early stopping, as the score keeps decreasing, so #585 is still relevant even after this speedup.