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 prepares the way for spell checking, which is to be done
without context so without proximity info.
Bug: 4176026
Change-Id: I1b4bfaefe2611e1b484acdf3c33598cb80f81ff4
For German : handle "ae", "oe" and "ue" to be alternate forms for
umlaut-bearing versions of "a", "o" and "u".
Issue: 3275926
Change-Id: I056c707cdacc464ceab63be56c016c7f8439196c
ApplicationInfo.sourceDir may or may not be apk file name. It can be a directory as well.
The spec just says it's "Full path to the location of this package".
Also, added error handling in loadDictionary().
Change-Id: I5e64d0aba4b1ec7634f4b3ac5537e7a774433ece
Jean Chalard
Tadashi G. Takaoka
Ken Wakasa
Ying Wang
satok
Jean-Baptiste Queru
Yusuke Nojima