2015-10-21

At some point in my career I was working for a company that was developing a hand-held computer for the area of Home Health Care. It was called InfoTouch™. The job involved daily interaction with the guys in the hardware department, which was actually quite a joy, despite the incessant "it's a software problem --no, it's a hardware problem" arguments, because these arguments were being made by well-meant engineers from both camps, who were all in search of the truth, without sentimentalisms, egoisms, vested interests, or illusions of infallibility. That is, in true engineering tradition.

During the development of the InfoTouch, for more than a year, possibly two, the device would randomly die for no apparent reason. Sometimes it would happen once a day, other times weeks would pass without a problem. When it happened, no matter how hard we tried, we could never reproduce it. Also, some times it would die while someone was using it, but other times we would come into the office in the morning to find that it had died during the night, while sitting on its cradle, doing nothing but charging.

2015-10-18

Back in 1999-2000 the state of the art in computer telephony was called Interactive Voice Response (IVR). Nowadays when we speak of "voice" we usually mean voice recognition, but all that those telephony systems did back then was to playback recorded messages and wait for the caller to press digits on their phone. Sometimes, we would ask the caller to speak on the phone, and we would
record their voice, for a human operator to listen to later.

The hardware had special filters on it to recognize the DTMF digits, probably because the CPU was thought of as too wimpy to do it by itself. I experimented writing WAV-file processing filters on my own, and discovered that it took less than 10% of CPU time per phone line to run such filters in software, so it could certainly be done, but then again there existed systems out there in configurations of 30 or even 100 lines per computer, and of course the CPU was not enough in these cases. We only worked with configurations of four lines per computer, but still, since the filters were made available by the hardware, I made use of them for the work project, and I only re-invented the wheel at home, for fun.

My employer at that time managed to secure a number of computer telephony contracts for a couple of big clients; he gave me a rough description of what the projects were supposed to do, and he had my coworkers slide pizza under my office door for as long as it took me to complete them. He probably charged his clients the equivalent of a dozen programmers for this, and it was all done by me. The only external help that went into these projects was messages recorded by a professional at a recording studio.

What follows is some screenshots of the telephony application that I created to run these projects, in Microsoft Visual C++ using MFC and the Dialogic Telephony API.

Summary (just gimme the TL;DR)

You give it a crossword grid, and a long list of words, and it finds ways to mesh words into the grid so as to form a complete crossword puzzle. This is the kind of problem that cannot be solved by brute force, because it would take eons to complete. So, a simple AI trick is used: when it has a number of words to consider, instead of starting to try them all one after the other, (brute forcing,) it first assigns a score to each word based on how many words can be found perpendicular to it, then it sorts the list of words by score, and then it begins trying words starting from the one with the highest score.

The following 30-second video shows the crossword compiler in action, filling multiple successive crosswords using a word list taken from actual crosswords that have been published on the interwebz by various sources through the years. The video is in real time, showing that the crossword compiler is, in most cases, extremely fast.