It looks like you're heading in the right direction.
You're right that there isn't a single, global lookup table that tells you what to do for any pattern of input. Instead, each state effectively has its own lookup table, and playing "which lookup table do I want to use next?" is a significant part of the game.
Don't worry that it's taking time to get the ideas straight.. this is the bones of computing stripped bare, with all the challenges and none of the convenience padding. There are whole mid-level college classes devoted to this stuff. You've shown a lot of determination in coming back to the ideas again and again and trying to make them work. I've been where you are, and know how frustrating it can be.
The longer we go, the better I understand your take on the ideas, and that (hopefully) lets me offer better suggestions.
On that subject, let's try a simpler machine to emphasize the 'which lookup table do I use?' part: Two states, two input symbols, no extra stuff:
- If you're in state 0 and see a 0, stay in state 0
- If you're in state 0 and see a 1, move to state 1
- If you're in state 1 and see a 0, stay in state 1
- If you're in state 1 and see a 1, move to state 0
You could rewrite that with two lookup tables:
LUT_0: { 0:"use LUT_0 next", 1:"use LUT_1 next" }
LUT_1: { 0:"use LUT_1 next", 1:"use LUT_0 next" }
If we start with LUT_0 (an arbitrary choice) and see the input stream '1011000100', the machine does the following:
Code: Select all
using input result
----- ----- ---------------
LUT_0 1 use LUT_1 next
LUT_1 0 use LUT_1 next
LUT_1 1 use LUT_0 next
LUT_0 1 use LUT_1 next
LUT_1 0 use LUT_1 next
LUT_1 0 use LUT_1 next
LUT_1 0 use LUT_1 next
LUT_1 1 use LUT_0 next
LUT_0 0 use LUT_0 next
LUT_0 0 use LUT_0 next
How would you use such a machine? I'm not sure.. the basic action is 'stay where you are until you see a 1, then change', so I guess you could use it to control traffic lights.
Let's say state 0 means "red light on the north/south street, check north/south sensor for waiting traffic" and state 1 means "red light on the east/west street, check east/west sensor for waiting traffic". The input 1 would mean "traffic is waiting at whatever light is currently red".
From there, the machine decides:
- If no one is waiting, there's no reason to change the light.
- If someone is waiting, change the light to let them through.
If each state polls its sensor every 30 seconds, you get a basic traffic control system that doesn't keep people waiting when there's no cross-traffic.
So.. I guess that makes it an "alternate if possible, but take whatever's available" machine.
For comparison, a simple truth table wouldn't handle traffic as gracefully. You'd have two inputs for "traffic is waiting at the north/south stoplight" and "traffic is waiting at the east/west stoplight", and those would give you a table like so:
Code: Select all
NORTH/SOUTH
NO YES
+-----------------------
EAST/ NO | action-1 action-2
WEST YES | action-3 action-4
action-1 (no traffic waiting either way): Turn east/west lights green
action-2 (traffic waiting on north/south): Turn north/south lights green
action-3 (traffic waiting on east/west): Turn east/west lights green
action-4 (traffic waiting both ways): ???
The table only allows you one answer for what to do when traffic is waiting both ways, so one road would have an advantage over the other. If you choose "Turn east/west lights green" for action-4, people could be backed up for a mile on the north/south road, but the light will still change as soon as a car arrives on the east/west road.