This still returns the unigram frequency, because the values stored
for bigrams in the dictionary are not ready to be returned in-place
instead of unigram values. Aside from this, the code is complete.
Bug: 6313806
Change-Id: If7bb7b644730782277f0f6663334c170b7fe13fb
Passing the position will not allow us a reasonable lookup
time. Replace this with a map and bloom filter for very fast
lookup.
Bug: 6313806
Change-Id: I3a61c0001cbc987c1c3c7b8df635d4590a370144
We don't want to do a linear search on each terminal when there
may be 100+ bigrams for a given word because that would be
disastrous for performance. Also, we need to resolve each bigram
address anyway.
This change resolves the addresses at first and puts them in a
balanced tree so that lookup will be O(log(n)).
Bug: 6313806
Change-Id: Ibf088035870b9acb41e948f0ab7af4726f2cee24
The position itself is still a const int = 0 until we have the previous
word passed to the function. This basically does the plumbing.
Bug: 6313806
Change-Id: Ib58995f334fe93e3ff5704d7c79f332017f101ac
For now the probability is just returned with the same
value it had, but this is some ground work that needs to be
done anyway.
Bug: 6313806
Change-Id: I9bb8b96b294109771208ade558c9ad56932d2f8e
We need to get the bigrams during the call to getSuggestions for
bug#6313806. We already give an int[] to getSuggestions and we
wanted to get rid of char[]'s anyway because it doesn't work with
surrogate pairs, so here we go.
Bug: 6313806
Change-Id: I56ce99f1db6b3302cdf42f0527343bded837091e
This was introduced by Ieb2e306a which failed to keep the return
behavior in case the word doesn't have a bigram.
Change-Id: I6d2f0b79d41c4335e94696690c8331e314961133
Split out getting the pointer to the bigrams to a separate
function. This is a preparative change to bug#6313806
Change-Id: Ieb2e306a1151cd95dc1a16793c8dc2f7fed8b654
This leak was about 500k and would happen whenever a new binary
dictionary was opened/closed.
Bug: 6299535
Change-Id: I4fad5b4d9c556ca889f5ef62d9d083a2eff6346a
