Without personalization:
Total words: 1134774, Success Num: 899230, Success Percentage: 79.243%
Bad Failures, with auto-correction (typed word == expected word, output word != expected word): 1871, Bad Failure Percentage: 0.165%
Failures, with auto-correction (F-C): 29084, F-C Percentage: 2.563%
Max Keystrokes: 6072959, Min Keystrokes: 4436090, Keystroke Saving Percentage:26.953%
Before:
Total words: 1134646, Success Num: 925194, Success Percentage: 81.540%
Bad Failures, with auto-correction (typed word == expected word, output word != expected word): 1316, Bad Failure Percentage: 0.116%
Failures, with auto-correction (F-C): 28288, F-C Percentage: 2.493%
Max Keystrokes: 6072831, Min Keystrokes: 3946188, Keystroke Saving Percentage:35.019%
After
Total words: 1134659, Success Num: 944746, Success Percentage: 83.263%
Bad Failures, with auto-correction (typed word == expected word, output word != expected word): 1258, Bad Failure Percentage: 0.111%
Failures, with auto-correction (F-C): 28016, F-C Percentage: 2.469%
Max Keystrokes: 6072844, Min Keystrokes: 3387333, Keystroke Saving Percentage:44.222%
Change-Id: I3af42ec37a11847c0429c28616e726f6a339247f
Previously, when both legitimate 0-frequency words (such as
distracters) and offensive words were encoded in the same
way, distracters would never show up when the user blocked
offensive words (the default setting, as well as the setting
for regression tests).
When b/11031090 was fixed and a separate encoding was used
for offensive words, 0-frequency words would no longer be
blocked when they were an "exact match" (where case
mismatches and accent mismatches would be considered an
"exact match"). The exact match boosting functionality meant
that, for example, when the user typed "mt" they would be
suggested the word "Mt", although they most probably meant
to type "my".
For this reason, we introduced this change, which does the
following:
* Defines the "perfect match" as a really exact match, with
no room for case or accent mismatches
* When the target word has probability zero (as "Mt" does,
because it is a distracter), ONLY boost its score if it is a
perfect match.
By doing this, when the user types "mt", the word "Mt" will
NOT be boosted, and they will get "my". However, if the user
makes an explicit effort to type "Mt", we do boost the word
"Mt" so that the user's input is not autocorrected to "My".
Bug: 11031090
Change-Id: I92ee1b4e742645d52e2f7f8c4390920481e8fff0
If the user has chosen to block offensive words and types
"aaaxbb", where "aaa" is an offensive word and "bb" is not,
we should not suggest "aaa bb".
Bug: 11031090
Change-Id: Ie23b8dd5d347bc26b1c046c3f5e8dfbc259bf528
(This is a cherrypick of http://ag/576739)
Also, modify the IllegalArgumentException to capture the
values passed for start, end, and array.length to make
debugging easier in the unlikely event that it is thrown.
Add corresponding tests for the exceptions.
Tested:
tapas LatinImeGoogle LatinImeGoogleTests userdebug
make -j30 && \
adb install -r \
out/target/product/generic/data/app/LatinImeGoogleTests/LatinImeGoogleTests.apk && \
adb install -r \
out/target/product/generic/system/app/LatinImeGoogle/LatinImeGoogle.apk && \
adb shell am instrument -w -e class \
com.android.inputmethod.latin.utils.CollectionUtilsTests \
com.google.android.inputmethod.latin.tests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I0c579ca4f4f2a9b2575aa6f8fa75e3ee4a21cf8a
Correctly encoding possibly offensive words with their correct
frequency and the possibly_offensive flag set.
Continuing to encode with zero frequency only distracters or
words that should never come up.
https://paste.googleplex.com/5167060875214848
Bug: 11031090
Change-Id: Ia394b1827f292ff8d4791cc2f3e6e50b5aff4cbe
