mudasobwa
Vidar
From what that example show there is exactly one valid transition for any given current state. Where I think we might talk around each other (?) is that I consider the overall current state as a composite of state machine state and input states. (It might be a synchronous state machine thing as that is what I’ve used the most. Take the current state, poll the inputs, and there should only be one possible transition ahead for deterministic operation).
(Then there are hierarchical and more complicated ones, but I don’t think we are discussing those. At least I’m not.)
Anyway, flags are still confusing.
derek-zhou
A Mealy state machine is just a Moore state machine plus a state-less function that maps the outputs of the Moore state machine, the input to the Moore state machine, to a new set of outputs. Neither inputs nor outputs are states.
Vidar
Considering all the books about state machines I do not think our various short comments will be able to capture the full extent of state machines, their differences, or the every precise terminology as used in their many applications.
My naive understanding is that Moore machines have outputs depending only on state, with the next state depending on current state and inputs. In Mealy machines the outputs both on current state and inputs, and so do the next state. Personally I thought they could be converted back and forth, and the practical reason to choose Moore was more about avoiding electrical glitches when used with hardware. According to Wikipedia though not all Mealy machines can be converted to Moore machines, but I leave that rabbit hole for someone else to drown in.
I’ve mostly used state machines with electronic sensors, buttons, joysticks etc as inputs and controlling motors, relays and UI as outputs. The values of these are variables where the inputs reflect their current state, while for the outputs reflect what state I want them to get to. They are not states in the finite state machine terms, but they are nevertheless stateful variables which together with the FSM state describe the systems overall current state.
I agree different terminology for these different kind of states would be clarifying, and that in this setting states of inputs and outputs would better referred to as just variables. Nevertheless those variables do state though. If I got a latching button that is either on or off then that is holding state, and usually referred to as such. I don’t think you can convince me inputs or outputs do not represent state.
derek-zhou
It seems like you prefer to discuss FSM in the logic design setting. In this setting, there is a strong distinction between combinatorial logic (pure functions) and sequential logic (state management), states, inputs and outputs are rigorously defined. Outputs are combinatorial results of the state (or state plus input). One can say that outputs reveal state, but they are usually not the state themselves.
You may want to refet to the following introduction material.
Vidar
I had those same intro examples as home exercises back in the day.
- Inputs can be stateful and thus have state as the buttom example above. As for outputs they can similarly control state. Say turn on or off a switch or a light bulb to keep it simple.
- The states of the FSM belong to the FSM. Their existence does not take away that inputs can have their own state.
As far as I can tell we disagree that inputs can have state. I would also not count on being able to know FSM state based on the output as many states can give the same output.
mudasobwa
I would argue there is Michael Sipser’s Theory of Computation and the rest and I would not recommend reading the rest.
Vidar
That does seems like an interesting one. 
Edit: Actually available as open course on MIT. https://ocw.mit.edu/courses/18-404j-theory-of-computation-fall-2020/video_galleries/video-lectures/
derek-zhou
I am not sure we disagree on anything because I do not understand your points. Did you mean to say:
- inputs to a state machine could be outputs of another state machine, Of course, but then they are outputs, not states.
- outputs could be the states themselves through an identity function (like in your latching button case). Of course, degenerate case exists. But they are not states additional to what the state machine hold.
I think mentally separating inputs, outputs and states help me to reason about FSMs. YMMV.
Vidar
All I am saying is that inputs can have state. To me that is obvious, and I assume we simply have some communication error at some level here. So let me try once more:
-
An impulse button has no state. When used as input to an FSM pressing it becomes a one time event to the FSM. This would be the preferred option.
-
A latching button do hold state as it is either on or off. When used as en input to an FSM that provides either a constant signal of on or off. The FSM is still an FSM, and that button still do hold its own state.
I use stateful input on machines. Lets say a FSM controlled machine had a sudden power loss in the middle of an operation. The current state is lost, and so are all previous stateless events that brought it to that state. Stateful inputs can then help make sure the machine starts up again in a safe state, and can also help to resume operations from the earlier reached state.