Open jahorton opened 3 years ago
Given we are not observing current performance issues here, let's wait on this.
Related to #5312 ?
Related to #5312 ?
Nah, that has nothing to do with predictive text and everything to do with how the TouchAliasElement
operates. It's not exactly an optimized word-processing element.
Although ... good to think about both areas in tandem!
This is the sort of change that should happen early in a development cycle, by the way. Lots of chances for things to go wrong if something is broken, and I'm not convinced that all possible side-effects would be obvious.
Before taking in extra constraints specific to our use cases, I believe a major part of this problem can be rephrased as the "longest common substring" problem. When the context window slides, we expect most of the context string to remain intact.
An extra constraint I believe we can impose:
Note that this one constraint should dramatically reduce the runtime complexity of a would-be dynamic programming approach - we only need to check for matching substrings on the border of both ends. This should give us a O(n
+m
) time complexity, with n
and m
being the length of the two strings, rather than the O(n
*m
) we'd get if the longest substrings could start at any index within both contexts.
While there are faster generalized approaches - via use of a "generalized suffix tree" (as mentioned on the linked Wikipedia page) - that's a data structure I'm less familiar with, one we haven't used anywhere else in the project, and one that's notably more complex than a "start at each end and count" approach. I don't see a need to go "suffix tree" complex here.
That said, I imagine that the outcome of the discussion on https://github.com/keymanapp/keyman/pull/10662#discussion_r1480975734 will be relevant to whatever approach ought be taken for sliding window operations as well.
As noted, this is important... but is also definitely not trivial.
In terms of context passed through to the
KeyboardProcessor
, there would be little problem. As noted, keystrokes don't ever have that wide a range of effect.The major pain point would be retooling how suggestions and reversions are applied. The process for both involves comparing the "before" snapshot with the current context state, which gets tricky when context is represented by sliding windows. It does seem possible, though.
I do think we should have a "design" round before making such a change. There are a number of ramifications to think through, especially given how critical context synchronization is when embedded within the mobile apps.
Originally posted by @jahorton in https://github.com/keymanapp/keyman/issues/5248#issuecomment-858198679