State Machines - my brain won't do what I want it to
-
That takes me back a LONG time to my student days. It was an assignment I remember, writing something exactly like this in assembly on some 8 bit processor (6809 rings a vague bell). Can't remember how, but our programs could then be loaded into a board based computer connected to a miniature elevator for everyone to have a go at defeating other people's software. The tricky bit was deciding when to accept and when to ignore a request from a button push on a given floor or if e.g. someone presses a button to request a lift to take the up, then gets in and presses the button for a lower floor. Decisions would then be based on all the "in-lift" requests plus the "out of lift" requests plus the current direction of travel. Surprising fun and games for such a simple system.
Yep - needs rules real quick. Always going to the closest floor request would not be a good idea, e.g.
-
I'm trying to come with a simple article on building state machines. I figured it wouldn't be too complicated, nor should it be since I wanted the article to be accessible to beginners. The trouble is, I can't think of a simple example of a state machine that is real world at all, and I don't want to lead with something contrived because I also want to explain the "why" of state machines with a practical example. This shouldn't be very complicated. I've been writing state machines for various things since the mid 1980s. In all that time I must have done something simple, especially since I was coding on a 16-bit machine back in the beginning. Grrrr
Real programmers use butterflies
Reading input devices like a mouse, keyboard, joystick - without a fancy event based framework is a good example. Given that the hardware only gives you the state of pressed/not-pressed events like click, tap, double-click, etc. require and abstract state machine on top of the state of the physical buttons, and best of all most beginner programmers are going to understand the examples without needing any other domain knowledge.
-
I'm trying to come with a simple article on building state machines. I figured it wouldn't be too complicated, nor should it be since I wanted the article to be accessible to beginners. The trouble is, I can't think of a simple example of a state machine that is real world at all, and I don't want to lead with something contrived because I also want to explain the "why" of state machines with a practical example. This shouldn't be very complicated. I've been writing state machines for various things since the mid 1980s. In all that time I must have done something simple, especially since I was coding on a 16-bit machine back in the beginning. Grrrr
Real programmers use butterflies
Way back in the stone-age, I a state machine and a timer interrupt to implement a Serial port on a micro controller. Due to the efficiency of the state machine, I was able to handle 9600 baud in the background while the software handled its main task, probably driving a printer. I think that was state driven as well. It’s amazing what you could do in lees than 4K ROM and 120 byes of Ram, including stack. One of the big advantage of some state machine implementation is they take very little RAM.
"Time flies like an arrow. Fruit flies like a banana."
-
How about an elevator. Or a set of elevators in a building, programmed to most efficiently seek a state of best efficiency to service the next floor request when at rest. ...er *puff* yeah... something like that...
Tim Deveaux wrote:
How about an elevator.
I second that: if my memory serves me well, Knuth used it as an example in TAOCP (The Art of Computer Programming) and he didn't use FSMs (I'll have to go review that). If Knuth himself used it, it must be good. Mircea
-
I'm trying to come with a simple article on building state machines. I figured it wouldn't be too complicated, nor should it be since I wanted the article to be accessible to beginners. The trouble is, I can't think of a simple example of a state machine that is real world at all, and I don't want to lead with something contrived because I also want to explain the "why" of state machines with a practical example. This shouldn't be very complicated. I've been writing state machines for various things since the mid 1980s. In all that time I must have done something simple, especially since I was coding on a 16-bit machine back in the beginning. Grrrr
Real programmers use butterflies
There's a bunch of articles on state machines already here on CP. Games, like Hunt the Wumpus - Wikipedia[^] are perfect examples for using a state machine. BTW, I actually knew Gregory Yob, he was very much a mentor to me in my early 20's.
Latest Articles:
Abusing Extension Methods, Null Continuation, and Null Coalescence Operators -
That takes me back a LONG time to my student days. It was an assignment I remember, writing something exactly like this in assembly on some 8 bit processor (6809 rings a vague bell). Can't remember how, but our programs could then be loaded into a board based computer connected to a miniature elevator for everyone to have a go at defeating other people's software. The tricky bit was deciding when to accept and when to ignore a request from a button push on a given floor or if e.g. someone presses a button to request a lift to take the up, then gets in and presses the button for a lower floor. Decisions would then be based on all the "in-lift" requests plus the "out of lift" requests plus the current direction of travel. Surprising fun and games for such a simple system.
Speaking of elevators, I've always wanted to ask if repeated button pushes get precedence. It would explain why when I'm standing there and the button is already lit, others feel the need to press it again, sometimes repeatedly. Do they know something I don't?
"Go forth into the source" - Neal Morse
-
How about an elevator. Or a set of elevators in a building, programmed to most efficiently seek a state of best efficiency to service the next floor request when at rest. ...er *puff* yeah... something like that...
Surely elevators don't use state machines? The basics could be done with a state machine, but what about if multiple floors are selected from multiple people in the lift? What if I go from 2 to 20 and someone on 15 presses up? What if they press down? It's surely too complex?
-
When I hear "state machine" I think of games. Maybe you could write something about that? Also, don't know if I used it right, but I once used a state machine for order processing. The order could go from "ordered" to "paid" and "paid" to shipped, but never "ordered" to "shipped", or something like that. It was a bit more complicated than that, but it's been a while so I don't remember, but it was something like that.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Unity uses FSM to manage AI and general game play flow.
-
Surely elevators don't use state machines? The basics could be done with a state machine, but what about if multiple floors are selected from multiple people in the lift? What if I go from 2 to 20 and someone on 15 presses up? What if they press down? It's surely too complex?
Maybe simplify it - each 'floor' (like a cell on a Turing machine) has a signalled state - off, on wanting an up pickup, on wanting a down pickup, or on as a destination. And the elevator is always moving through all floors, in one of the two directions. If the elevator polls each floor state as it approaches it and reacts accordingly, it doesn't matter whether the signals are set inside or outside the elevator. Lots of subtleties to add on of course (bloody feature creep) but...
-
I'm trying to come with a simple article on building state machines. I figured it wouldn't be too complicated, nor should it be since I wanted the article to be accessible to beginners. The trouble is, I can't think of a simple example of a state machine that is real world at all, and I don't want to lead with something contrived because I also want to explain the "why" of state machines with a practical example. This shouldn't be very complicated. I've been writing state machines for various things since the mid 1980s. In all that time I must have done something simple, especially since I was coding on a 16-bit machine back in the beginning. Grrrr
Real programmers use butterflies
A bank account is an excellent example of a state machine, since it can be viewed on different levels. For the bank your account is on one of two states: you have either money or a dept. For yourself you might add states like a. positive saldo b. overdraft (i.e. nearing the end of the month) c. too much for a regular bank account: need to transfer to a saving account So, dependent on the view you take you can identify a few states your account is in
-
Speaking of elevators, I've always wanted to ask if repeated button pushes get precedence. It would explain why when I'm standing there and the button is already lit, others feel the need to press it again, sometimes repeatedly. Do they know something I don't?
"Go forth into the source" - Neal Morse
That obviously depends on the software. Many years ago, I was working on a timesharing minimachine (16 bits CPU, half a megabyte of RAM) serving 20 simultanous users, so the CPU was quite heavily loaded. Even a moderate size student program took minutes to compile. Some guys (students, of course) discovered that when you hit a key on the keyboard, the OS would raise the priority of that user process for a brief period. This was to give good interactive response. If the process was still in the running state after a couple of seconds, it was probably doing some lengthy processing, such as a compilation, and given lower priority that those processes in an active user dialog. What these students discovered: Priority was raised on keyboard interrups even when the process was not waiting for keyboard input. If they had a lengthy compilation, they could rest a finger on the space bar for a continous stream of keyboard interrupt, so that their compilation was done at "interactive" priority, pushing the jobs of the 19 other users aside, in effect taking all of the capacity of the CPU. This worked as long as you were the only one knowing this trick. Of course it leaked out, and soon all 20 users ran their compilations competing for the CPU at interactive priority, no different from when they had been competing a "background" priority earlier. But if there were one user actually trying to get some interactive work done, it was almost impossible, with heavy compilations running at the same high priority. We reported this problem to the vendor, and in the next release of the OS, the priority was raised only if the process was actually waiting for keyboard input, not when it was busy compiling. The students frequently commented that the OS textbook was wrong: It stated that timesharing makes it appear as if you have the entire machine to yourself (that was a common claim in OS textbook of that age). The students argued that truth is exactly the opposite: It makes you realize that you do not have the machine to yourself! The situation with you as the only one trying to edit a source file with 19 compile jobs artificially raised to the same priority is an extreme example of that. For the elevator: Pressing again will certainly not speed up the motors pulling the carriage. If it were to have any effect, it would be because the control logic said something like: "Sure, I was on my way up to pick up that person on floor 12, but those guys down at floor 2 are nagging me so much that I'll
