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
Jean Chalard
Tadashi G. Takaoka
Ken Wakasa