Show HN: Interactive, Visual Explanation of the GRAIL Handwriting Recognizer | Hacker News Reader

Show HN: Interactive, Visual Explanation of the GRAIL Handwriting Recognizer

jackschaedler.github.io

119 pointsjackschaedler18 comments

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".

Thanks! I'll take some time this evening to make it a bit better at picking out the K.

I also had problems with "K"; I think the issue is that it does not recognise strokes where the second direction is right (rather than up) as a "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.

Worth looking at the linked video. Pretty impressive what they could do using late 1960's technology.

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, ...).

[1]: https://www.youtube.com/watch?v=QQhVQ1UG6aM

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.

for recent(ish) activity https://depts.washington.edu/aimgroup/proj/dollar/

Nice demo. I've never been able to get it to recognise B, no matter how I draw it.

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"

Same thing for me on O. I tried clockwise, counter clockwise both failed.

Then I tried starting from top instead of bottom. Don't people start from bottom? It should be easier to align.

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...

Great! The linked demos give a very creative feel.

Reply on news.ycombinator.com