| Yes that's mostly it for such old elevators (see "Elevator algorithm" https://en.wikipedia.org/w/index.php?title=Elevator&oldid=10...), except: - The elevator has a "home floor" (the lobby/ground floor) that it returns to by default, if it has nothing else to do. (Apparently many elevators do this; see "Up peak" in the linked post or on Wikipedia https://en.wikipedia.org/w/index.php?title=Elevator&oldid=10... .) - To set up such a discrete event simulation on a computer, you also need to model timing (how much time it takes to open and close doors, to move between floors with acceleration/deceleration, etc), and users (how many arrive at each floor and when, and where they want to go to, how long they wait before giving up). - So you end up with a fair amount of state (the "up" and "down" call buttons on each floor, the buttons inside the elevator, whether the elevator is going up or down or neither) and control (when to open or close doors: what to do if someone presses a button while the doors are closing, etc). - The purpose of that section of TAOCP is to show in detail how to use doubly-linked lists to simulate such things on a computer (which here means getting down to the level of memory layout and assembly code: MIX/MMIX). So overall there are ~5.5 pages of describing the algorithm, ~1.5 pages for memory layout etc, ~7 pages of assembly code, and a page of higher-level stuff mentioning programming languages and profilers etc. I'm aware of two repositories on GitHub that reproduce this simulation in a higher-level language: https://github.com/meatfighter/knuth-elevator (700-odd lines of Go code including comments from TAOCP) and https://github.com/Quuxplusone/KnuthElevator (500-odd lines of C++14 code without the copied comments). (Learned of the latter via https://www.meetup.com/theartofcomputerprogramming/ a meetup for reading TAOCP.) |