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
The build system does not work well with ".." in the path of native
source code.
".." causes the object files to spill out of the module's intermediate
directory.
Change-Id: Ib4a473426be296a738e7facbaa091e56f0b7c5b8
This breaks style guidelines but for some reason git diff gets
so lost on this re-indent that it's better to do it like this
Change-Id: Ie0a603eb0739704894a5adc25f9d527b37bdf151
This results in the computation being done in native code
and the correct proximity being used.
Bug: 6181080
Change-Id: I08fa05c781d607e4feca2caeda353ec19c133a3d
The digraphs system used to allow only the replacement of
a pair (A, B) by (A). This change allows the replacement to
be any character.
Bug: 5140033
Change-Id: Icf5995f0ec553f7b7989af9902cbb2c4c6b51009