Nice demos. This is what "literate programming" should be like really :)
It is unfortunate that it can't recognize lowercase/uppercase, and that F and X have to be drawn in a quirky way to be properly recognized. Also I had problems with inputting "K".
This looks 99% identical to what Palm developed as Graffiti. Graffiti ran nicely on a 16MHz (later 33MHz) 68030ish microprocessor with 512KB of RAM and a 160x160 LCD display with a resistive touchscreen.
I think that I'm faster on an Android soft-keyboard with prediction and sliding, but not by very much.
Thanks for this wonderful essay! I love learning about that period in computing, when a lot of what we use today was first challenged. It's easy to see how those same principles apply to the GRaIL visual programming interface demo[1], where different strokes create different types of elements (boxes, outputs, connections, ...).
It reminds me of the Palm handwriting recognition system. I liked there was no pretensions of natural handwriting recognition on the Palm. The awkward way you had to draw letters with the stylus was part of the UI, so little stroke order hints were displayed on the screen while you were writing. It made for a fairly efficient input system after a bit of practice, like txting on old phones.
I assume the Palm system worked on similar principles to GRAIL.
It could be worth mentioning that, for thinning points, ideally you'd use a circle, so that points are thinned equally in all directions. When you use a square, diagonal lines are thinned more (by a factor of sqrt(2)) than horizontal/vertical lines. However, checking inclusion within a axis-aligned square requires only comparisons/subtractions, but checking inclusion within a circle requires square roots and squares... certainly a big deal back then.
This is a great point. When I first implemented the visualization, I actually used a circle until someone pointed out to me that the formula describes a square region around the datapoint and not a circle. I think you are very right in saying that this decision was made by Groner solely for efficiencies' sake in 1966. I'll probably add a side-note to explain this a bit.
This is great! You've already linked to Bret Victor's work, but I'll pay you the compliment of saying this essay and demonstration is up there with some of his productions.
I'll take some time tonight to make it a bit better at dealing with different shapes of Bs. If you want to know what the 'canonical' stroke pattern is, you can click on the little graphics above the tablet. They will animate to show you the expected stroke path (although, it should just work, so I'll fix that tonight)
It didn't work with how I normally write B either (drawing downwards from the top-left corner), but I did find a method that worked: start at the bottom-left corner, move up to the top, then draw a "3"
Oh goodness, haha. Doing this project I've learned that there is a great deal of variety in handwriting style. Single-stroke vs. Multi-stroke 5 for example, seems to be a big point of contention. I'll extend the decision tree to be more friendly about bottom-starting strokes.
I start many of my letters from the bottom, and everyone tells me I write opposite-handed. This recognizer definitely had problems with the way I would naturally write a lot of the letters...
It is unfortunate that it can't recognize lowercase/uppercase, and that F and X have to be drawn in a quirky way to be properly recognized. Also I had problems with inputting "K".