| Donald Knuth's The Art of Computer Programming has, in its first volume, a lengthy section on simulating an elevator. It is a single regular elevator (nothing "special" going on as in the post here), but even so, as he tries to make things precise, you realize how much detail is involved, and get some appreciation for the task of programming. It occupies about 15 pages (plus several pages of exercises and solutions). Knuth started working on TAOCP when he was a PhD student at Caltech: > The program developed below simulates the elevator system in the Mathematics building of the California Institute of Technology. The results of such a simulation will perhaps be of use only to people who make reasonably frequent visits to Caltech; and even for them, it may be simpler just to try using the elevator several times instead of writing a computer program. […] > The algorithm we will now study may not reflect the elevator’s true principles of operation, but it is believed to be the simplest set of rules that explain all the phenomena observed during several hours of experimentation by the author during the writing of this section. […] > The elevator system described above is quite complicated by comparison with other algorithms we have seen in this book, but the choice of a real-life system is more typical of a simulation problem than any cooked-up “textbook example” would ever be. It ends with: > It is hoped that some reader will learn as much about simulation from the example above as the author learned about elevators while the example was being prepared. And one of the exercises adds: > It is perhaps significant to note that although the author had used the elevator system for years and thought he knew it well, it wasn’t until he attempted to write this section that he realized there were quite a few facts about the elevator’s system of choosing directions that he did not know. He went back to experiment with the elevator six separate times, each time believing he had finally achieved a complete understanding of its modus operandi. (Now he is reluctant to ride it for fear that some new facet of its operation will appear, contradicting the algorithms given.) We often fail to realize how little we know about a thing until we attempt to simulate it on a computer. |
On one of the better teams I’ve worked with the water-cooler activity was trying to come up with an algorithm to describe the behaviour of the Coca Cola machine in the kitchen.
It was one of those clear plexiglass front machines where after punching in the coordinates of the item you wanted, a mechanical arm would move to the coordinates, take a drink, and place it in the delivery bay at the bottom.
While it would always get the drink you wanted, it would rarely go to the exact coordinates you specified. Ie, if there were three columns filled with coke, and you punched in the coordinates for the one on the far right, the arm may take a can from the center, or left column.
We would often wager a can of coke (“if I can’t find anything wrong in your PR, I’ll buy you a coke”), so we were perhaps drinking more soft drink than was medically advisable, but in our defence:
a) the machine was really cheap (AUD$1 or $1.5)
b) it was an excellent 10min break game
Eventually we thought they had it figured out we would gather and make our predictions, but occasionally there would be an upset that would throw a wrench into the model.
We got to a point where we just couldn’t reconcile the machine behaviour with any kind of coherent set of rules, then one morning we saw the delivery guy stocking it.
After chatting with him we learned our algorithm was more or less correct, but the internal state of the machine was prone to getting out of sync with the actual stock levels, so it would make the “wrong” choice near the end of the refill cycle. Then he gave the engineer talking to him a free energy drink (source of stock problems right there haha)
While we were no Knuths, I love that these kinds of games are so universal among engineers/devs. In fact, if I can get someone to tell me a similar story of theirs in an interview (for a technical role) I’m much more likely to consider them for the position. Curiosity is a powerful trait for a developer.
…and the (simple) algorithm for the machine is: Take from the column with the most stock, if there are multiple columns with the same stock level, take from the column furthest to the left.