On Mon, 2008-08-18 at 14:49 -0800, David Abrahams wrote:
on Mon Aug 18 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Sun Aug 17 2008, Darryl Green <darryl.green-AT-aanet.com.au> wrote:
in this trivial FSM where much of the state is directly encoded in a couple of variables,
I don't know what the number of variables has to do with anything. For all practical purposes, unless you allow nested states or other esoteric extensions to the traditional CS meaning of FSM, 16 bits is more than enough to encode the state of arbitrarily complex state machines.
I'm sorry, I don't follow you. The question was not about how to encode the state but about whether FSM concept is needed here.
I'm as baffled as you are about why Darryl brought up the number of variables required to encode the state. :-)
I assumed we all agreed that the number of variables required to encode the state is 1, and that the number of bits required was/is utterly irrelevant. My point is that the example is so trivial that it didn't need an FSM. Andrey had said effectively the same thing but it degenerated into a debate about input checking. I was trying to approach it from a different angle to avoid that. Last try: The following is not an FSM by any reasonable definition and implements the same behaviour as Phils code. Is it now clear why I was saying that the whole discussion surrounding this non-FSM is completely non-productive in evaluating the utility of an FSM library? struct usb_device { bool power; int address; int configuration; void power_on() { power = true; } void power_off() { power = false; address = 0; configured = 0; } void reset() { power = true; address = 0; configured = 0; } void set_address(int addr) { address = addr; } void set_configuration(int cfg) { configuration = cfg; } };