Fun to play around with that! https://archive.org/details/palm3_ghelp16 (click the power button to start the emulator, then click the Home button, then click the Graffiti app)
It's because the algorithm is easy to implement and efficient in terms of compute usage to match a gesture. It's a "cheap and easy" recognizer, a $1 recognizer. The name has spawned a whole host of similarly named papers which you can see on their "impact" page https://depts.washington.edu/acelab/proj/dollar/impact.html.
You have to know contextually that the dollar sign and the digit are part of the name before you can read any sentence that contains the name. That guarantees that you will be confused at least once!
That's funny cause I assumed this was expensive the other day and didn't check it out. "$1 for each recognition? Not worth the effort to even check it out"
I think the name is genius, you'll never forget it and if you ever need to implement a basic stroke recognizer you'll undoubtedly think of this. At least this is what I have done many times in the last decade.
It does not seem to recognize 'left handed' versions of the gestures. Try to draw a curly brace from the bottom up, or the star in a counterclockwise pattern.
I cannot seem to draw a right curly brace in a way that it recognizes it. It's almost as if the recognition was rotation-invariant because I sometimes get v or check as a false positive for }.
I can draw a } that it will recognize, but it takes special effort. A natural } that no human would have difficulty with tends to be "recognized" as a ] instead. Even when there is a VERY prominent center point protruding from the shape.
I also have trouble with the registered "arrow" shape - if you overshoot the point when you're doing the return from the top half of the arrowhead, you'll get recognized as a random non-arrow shape.
The "x" does not match the way I would naturally write an x, and it really highlights the fact that many common shapes are not drawn in a single stroke. (Also a problem for the arrow, as well as the "delete", which is clearly supposed to be visually identical to "x". It will be a problem for a large number of important characters that don't exist in the demo, such as A, t, and +.)
Between that and the fact that it has so much trouble recognizing }, which is visually distinctive and is naturally drawn in a single stroke, this doesn't seem like an algorithm you'd want to let users interact with.
Adding a single example of a } as drawn by me more or less removed that recognition problem. It introduced a symmetric problem where obviously squared-off ] was recognized as }. Adding the perfectly squared ] as an example of "right square bracket" reintroduced the inability to recognize very obvious }. I suspect this is not a solvable problem without switching to a more effective algorithm.
The whole family of algorithms (including the multistroke variants) suffer from this issue. They are very clever, and maybe suitable if your set of templates are sufficiently distinct, but they don't deal at all well with similar shapes
It doesn't support straight lines (1D lines), like a single stroke right. According to the PDF you need to implement your own bounding box analysis for this.
I was reading about it this week because I needed a gesture recognition library but haven't found anything else.
