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.
The unigram table we've been using is massive (10M-100M element array).
As such, when this gets saved to disk, it takes up a lot of space.
But really, all it is is a long array of numbers that are repeated based on the frequency they're expected (across all words).
E.g if you had words with equal counts, the number of their indices would be the same in the unigram table. And if you had some that had far higher counts, they would be far frequent in the unigram table.
What this PR does is remove the unigram table in favour of another approach.
This new approach finds the frequencies of all words, and then finds the cumulative probabilities (which is a sorted array starting near 0 and ending at 1 since we're adding up all the probabilities) for each word index.
And when it comes to getting indices for negative sampling, it finds the indices using
np.searchsorted
which finds the indices the generated random numbers (between 0 and 1) would need to be added to maintain order of the array.The PR also adds a test that makes sure the new method maintains expected frequency of words (in a simple example).
There are a few advantages for this new approach:
vocab.dat
will be smaller** NOTE: The currently most prevalently used vocab has a unigram table with length 10M, but the defaults are now (for a long time) 100M so if a new unigram table is calculated with no extra input, we get 100M length unigram table.
** NOTE: The number of samples required at a time is dictated by the context vector sizes defined in the config (
config.linking.context_vector_sizes
). These are (by default) 3, 9, 18, and 27.