Supporting nondeterministic and empty (epsilon) transitions about javascript-state-machine

[jakesgordon]

No, had not thought of that before. Sounds interesting.

For nondeterministic transition how would the choice be made - some sort of probability distribution ? That could be fairly easy to implement.

For epsilon transition - I might have to go do some reading to find out exactly what you mean - are they transitions that occur at unpredictable times without an explicit event call ? what causes them to fire then another probability distribution ?

Don't really have any particular goals for the library. It started out to help with managing state for some simple HTML5 games... I could imagine more advanced games could use features like these.

I should go do a little reading...

[izuzak]

Yep, the wikipedia article is not that bad for starters.

The implementation of nondeterminism and epsilon transitions kind of depends on what you want the library to be used for. If it is going to be a library for providing a theoretical framework for working with FSMs, then the implementation should follow the rules of FSMs as in the wiki article. That means that the model should not include probabilities and that there is no concept of choice, rather the FSM enters two or more states after a nondeterministic transition (i.e. the current state of the system is a set of states of the FSM). For epsilon transitions this means that in any state the system would check if there are epsilon transitions available from that state to some other states, and it would add those other states to the current state (which is, again, a set of states of the FSM). This kind of model can then be used for various analyses and transformations -- the FSM can be minimized with regard to the number of states or input symbols, you can compute the reachable states, etc. etc.

However, if you want the library to be used for practical modeling -- then, yes, the model should provide a way to define practical factors such as probabilities. And these probabilities could be used to pick a state from a set of states in a nondeterministic transition and the system would always be in a single state. This is more similar to real systems since real systems can't be in two states at a time, but also limits the usage of the library for theoretical modeling and analysis. For example, it is possible that a machine created using this approach never enters a specific state although there actually is a small probability of entering that state. This is bad for testing and verification since it is nondeterministic :)

A third approach may be to have a combination of the two approaches -- you permit the definition of probabilities for transitions (As in the second approach), but the FSM transitions to a set of states (as in the first approach). However, after making a transition, the FSM remembers the probabilities of each state it has transitioned to. So, the current state of the FSM would look like: [ { name : "state1", probability : 0.99}, { name : "state2", probability : 0.01}]... and by making more transitions, you add up the probabilities from the previous state. I like this approach since it's adaptable two any use-case.

Anyway, it's an interesting thing to think about for the future of the library :).

[jakesgordon]

Definitely seems like a good advanced feature to have in the future, but most likely wont get done any time soon, sorry. I'll keep it on the TODO list.

Thanks!