This is awesome! I saw your new video on FSM pop and started watching it. As soon as you mentioned this video, I came to watch this instead. I’m learning Python currently. This is a huge eye opener! Thank you! I’ll go watch the newer video now 😊
When I was earning my master's degree, I heard a lot about finite state machines (FSMs), but it was all theory - like clouds in the sky: there's a lot of water, but you can't drink it. I toiled for three months after graduating until I implemented my first FSM in code in 1981. Now, there is a programming methodology based on this concept - v-agent oriented programming (VAOP) - with many examples of its implementation. It's best to start learning about VAOP with this article on Medium: "Bagels and Muffins of Programming or How Easy It Is to Convert a Bagel into a Black Hole".
Additional videos on the topic would be good. I write my states rather differently, and have variations based on the nature of the input data. For lexical scanning like your number validation FSM, I would have the accepting states all transition to the "valid" terminal state on the EOI (end of input) state. All states would transition to the "error" state if any unrecognized input was received, and for the non-accepting states, EOI isn't recognized. It might be fun to show how FSMs of this sort are mapped to regular expression syntax, since an RE is often the best way to parse input tokens from a character stream. Of course, FSMs are useful for a lot of things that RE can't be used.
This makes me so happy for high level languages! I don't know how you low level guys do it. I know this is an example of a fundamental computer science concept but if I had to program in this manner all of the time I would lose my mind! That's why I will never touch assembler! For me personally I don't care for anymore on the topic but the more sophisticated in your audience certainly may. Anyway, thanks for the great info. I'm really enjoying your channel!
FSMs are a basic but fundamental concept that's the backbone of most software. I'm not really the audience who needs it, but I'd like to see more videos like this that cover basic design principles. Or FSMs in Go.
This is irrelevant to the purpose of this video, but in Canada, there is no yellow light when transitioning back to green. I learned as a small child riding with adults that you could anticipate the green light by observing the orthogonal lights' yellows, but if you're at a red here, don't expect any help, the green will just pounce upon you with no warning.
Sorry, Gary get gets close to, but not quite there. Sure, if you have had a course in compiler design, you already know this - however, if you haven't had such a course then I suspect making the connection is rather difficult.
@@RobertBartlettBaron You have a point that it's not quite there, but to be fair (and pardon me if this is very apparent, but) if he'd be explaining compiler design, then the video would've been named "Compiler design". Not making the connection is fine. These are soft-skills that will come to the surface whenever people do decide to take a course in compiler design, and subsequently, they'll pick up on the intricacies much better. RIght now it's handily packaged in an entertaining video, and the knowledge will hang around until it's needed. (insert witty reference to interrupt handling) But yeah, that's exactly why I called it a headfake. Gary makes us learn skills that are potentially useful in more than one field.
@@devjock I realize he is not explaining compiler design (see the original post for context), but he also doesn't mention the relationships between regular expressions and finite state machines, nor does he mention common applications that they are used in.
@@GaryExplains I looked at the views after commenting, I figured that would be your answer. But if it makes you feel happy, this video helped me more than any other in this year.
Hi Gary. I was a bit surprised that you made a video about FSMs, but as a programmer I really enjoyed it, and I think you explained it very well. (btw I also enjoyed the videos you made a while ago about writing a "software CPU") I'd like to see more videos about FSMs, in C (which I know but I find the subject interesting) and Rust (which I barely know, and am curious about). I think a video about FSMs for Game AI in Python would be very interesting as well.
@@GaryExplains I was surprised because I've mostly seen videos about hardware stuff (which I also like) on your channel lately. Even though there has been programming videos before, of course. But it was a pleasant surprise :)
@@CedLePingouin Understood. Thanks. Yes programming videos are also part of my repertoire. I have videos on C, Rust, Python, linked lists, sorting, and more.
Hey Gary, In few days I will have an exam for digital system and I'm revising for fsm and can't believe you uploaded this video. Thank you. Will watch this to understand it better.
Would like if you did a some videos or a series on FSM for AI using python. If you could also explain some Graph Search Algorithms like RBFS in that series then that would be great
@@GaryExplains oh, I guess I missed the notification. I'll look for it! Thanks to RUclips's stupid recommendations, now I have too many channels with notifications enabled :(
FSM in C and comparing to Python for a simple example would be usefull. Having written many large and complex progams running on MCU's without FSM's it would be good to know the best preactice process / steps for using FSM's.
Hi garry thanks for this topic was wondering for a video where how regular expression are implemented. Not how to use matcher in java or c rather how to write own regular expression matcher logic .
What a timing! I just started Cpython internals book which talks about Finite State Automaton very briefly. You video made it much more clear. Thanks Gary
Second thought, I don't think a person who wasn't interested in this topic would watch the whole video and then comments after, they'd just move onto something else.
I have used this for probably ALL my working life, wasn't called FSM though it was called Logic. Initially Relay Logic then Solid State Logic, then PDP8 then PLC(Ladder or CSF) and then Computer directly. Then retirement. I have drawn a State Machine for a Client but only after the fact. The Loop Back was illustrated by a on the connecting line btw. Problem with basic State Machines is that they insist upon only a single change in State whereas my field of Machine Control often requires multiple Branching and coming back together. That requires passing to another State Machine (not sure why 'Finite' in there), not sure at this moment how you would comeback together. I preferred roughing out a program using a sort of pseudo 'C' in which what you are showing would probably be a 'Case' statement. I am almost twenty years out of date now and certainly not 'Current' and Python has come along during that time and do not like it very much. Try a version of 'C' or Assembler (my preferred) and by inference the Arduino version of 'C'. The machines I wrote Control for could quite happily mangle you or more importantly the Operator very badly so this is not a flippant subject for me.
Ladder logic is used to implement state machines. Sometimes many simultaneous state machines. Ladder Logic also deals with analog signals pretty well, whereas most FSM you're going to see written in Python will be dealing with far less complex "real world" situations, since the beginner is not really ready to deal with hysteresis, feedback loops, and process control timing, where a difference of 0.0002 seconds (200 microseconds) might be the difference of diverting a bottle on a conveyer that failed visual inspection into a reject bin or kicking the bottle so hard that it smashes on the wall (or hits a factory worker if you're very unlucky). I have great respect for PLCs, Logix controllers, and other such devices, and for the people who program them well. I studied various forms of state machines in college, did some embedded programming and compiler development in various jobs after college, and over the years, most of my significant work involved extensive use of state machines. It was about 20 years after I graduated from college that I first started working with PLCs, but I picked it up pretty quickly. Still, it took me a while so that my code could compensate for cranky pneumatic actuators that changed performance significantly from when the bottle inspector was turned on to about 15 minutes of running once the rubber pressure hoses had stopped softening. The reason they're called "Finite" is because there are a countable number of defined states the state machine can be in. There are many kinds of FSMs, ranging from simple accepting automata which have a single "start" state and have terminal states, and really don't branch a lot, but there are much more complex FSM. Often, it is easier to create multiple linked state machines, each having its own independent state, but with synchronization points where they can affect one another. Deterministic Finite Autonoma (DFAs) are predictable and will always behave the same for a given set of inputs, but there are other kinds that, although the state transitions are well defined, the outcome for a given set of inputs can be different based on some external influence such as a random number generator. There are push-down autonoma that have a state stack (Turing machines), "Finite State Machines with Oracle" that depend on an external process to determine state changes, and so on. Regular Expressions are "Accepting Finite State Machines", and are good for parsing serial input data. My typical FSM for power sequencing of a circuit board defines each state in terms of the entry conditions, a list of actions to take on entry to the state (handled by an "enter state" procedure), a list of exit conditions each with the state that condition causes transition to, and an "evaluate" procedure that is called or event (timer, interrupt, etc.) handling, and in which the exit conditions are evaluated and the exit handling and transition to the next state is signaled when a matching condition is found. In C or Assembly, all states are represented as 'structs' that have function pointers for the "enter state" and "evaluate" entries (some also have a "reset" function pointer), and the FSM is driven by an outer "super-loop" that may run multiple parallel FSMs for different purposes (eg, asynchronous communication, watchdogs, key decode, A/D, etc.). What I do is often safety and time critical, and frankly, a "switch" statement isn't going to cut it. I always start out with a directed graph of the states, labeling all of the edges with the conditions under which the that edge is followed. A lot of analysis gets done on the graph before the first line of C code is written, though typically, the graph gets modified as the interactions between the FSM implementation and the hardware it runs in become better understood. After burning out a few $800.00+ FPGAs, you learn to be very careful about FSM design. Many real-world FSM are most easily documented as a set of macro-states which are each smaller FSM made of of "micro-states". In these cases, rather than having a lot of parallel FSM that interact, you can think of it as either a birds-eye-view of a single gigantic FSM or an FSM made of "black box" states that are much simpler than the top-level FSM in which they exist. I'd much rather do formal documentation for 16 FSM each with around 10 states than one FSM with 160 states.
That is a lot of information and I wxpect I know most of the things you are referring to by different descriptions. I am not comfortable with expressive abbreviations and those things which sound cute as well so I just use them as is. I do not prefer Ladder Logic if there is a choice. Seimens PLC, which I used often had a Logic Block Form and a sort of Assembler form They called them Control Flow System (CFS) and Statement List (STL) which were far more flexible and "Leaner". The last version I used almost twenty years ago, S7 could even be considered Object Type with a bit of imagination using local and global variables very nicely. I do not recall a State Machine type of function. I created Step Functions (the design is within their literature) with Set/Reset blocks formed into Sequence Steps with the time critical stuff going off in dedicated modules and in the background. I do not believe that you can get a meaningful timer of less than a tenth, maybe 0.05 with a PLC without very careful program layout because of the Scan Time Issue. The last time I added a scan time indicator into a program (using an S5-115 generation unit at the basic end of the range) where I was concerned about reaction time and wanted to check before I decided to use an expensive interupt type module it was about 15ms and I only need 30ms so I stayed with the cheaper solution. Processors are much faster nowadays up from 4.77MHz to lots of GHz now so I expect that PLC have speeded up too. My current knowledge of the subject remains the same as twenty years ago, not kept up-to-date. I will read your reply again more carefully. It was interesting.
Wouldn't mind at all to do this in another language. Wait.. Norwegian? Just kidding. But my teacher was a stickler for grammar as we did something like this on the BBC Micro and Turbo Pascal at the end of the 80s. We had bespoke norwegian made machines with around 220 Kb, the odd memory was for some graphics indeed.
@@GaryExplains It's much easier to do: switch(state) { case 0: (do something here) state=1; case 1: (do something else here) state=nth; case nth: ... default: printf("I'm done."); break; } Than to do all that python stuff. Enums make it much better. Python seriously needs switch statements. They just jump to a point in memory rather than check conditions.
@@chudchadanstud No, sorry, I don't agree. My Python code is just one line to know what handler to call to "do something". 1 line for 5 states and 1 line for 25 states, always 1 line. That case statement is hideous. Imagine if you had 50 states that would be a sprawling mess. Unreadable and unmaintainable.
@@chudchadanstud Also, the idea is to have a FSM that can be dynamically created, your switch statement is a hardcoded nightmare. Even in C you should be using a table of some kind.
@@GaryExplains Yes, you can work around it in many ways using, enums, abstract data structures, functions, pointers, OOP principals etc. It's also why I mentioned enums, with enums you don't have to use literals which will make tracking down things difficult just read the enum. An IDE can can track down every reference of an enum or auto complete. Order in the switchs statement matters less. It's also not a string so you'll notice typos before hitting compile.
This is awesome! I saw your new video on FSM pop and started watching it. As soon as you mentioned this video, I came to watch this instead. I’m learning Python currently. This is a huge eye opener! Thank you! I’ll go watch the newer video now 😊
When I was earning my master's degree, I heard a lot about finite state machines (FSMs), but it was all theory - like clouds in the sky: there's a lot of water, but you can't drink it. I toiled for three months after graduating until I implemented my first FSM in code in 1981. Now, there is a programming methodology based on this concept - v-agent oriented programming (VAOP) - with many examples of its implementation. It's best to start learning about VAOP with this article on Medium: "Bagels and Muffins of Programming or How Easy It Is to Convert a Bagel into a Black Hole".
Additional videos on the topic would be good. I write my states rather differently, and have variations based on the nature of the input data. For lexical scanning like your number validation FSM, I would have the accepting states all transition to the "valid" terminal state on the EOI (end of input) state. All states would transition to the "error" state if any unrecognized input was received, and for the non-accepting states, EOI isn't recognized.
It might be fun to show how FSMs of this sort are mapped to regular expression syntax, since an RE is often the best way to parse input tokens from a character stream.
Of course, FSMs are useful for a lot of things that RE can't be used.
I should be studying for my Digital Systems exam but I'm browsing RUclips instead. Then I see this video. Perfect timing.
Now you can do both!!! 😁
This makes me so happy for high level languages! I don't know how you low level guys do it.
I know this is an example of a fundamental computer science concept but if I had to program in this manner all of the time I would lose my mind! That's why I will never touch assembler! For me personally I don't care for anymore on the topic but the more sophisticated in your audience certainly may. Anyway, thanks for the great info. I'm really enjoying your channel!
These are totally underrated!
Tell me about it! 😊
@@GaryExplains Also check the Xstate JS/TypeScript lib, it's really nice and has a cool SM visualizer
FSMs are a basic but fundamental concept that's the backbone of most software. I'm not really the audience who needs it, but I'd like to see more videos like this that cover basic design principles. Or FSMs in Go.
What about PDA, push down automata, FSM extended by a stack. You could use it to verify/parse JSON.
Happy to get more content from you.awesome stuff sir !
Great explanation....🙂😀made complex term ...far easier...
Glad to hear that.
This is irrelevant to the purpose of this video, but in Canada, there is no yellow light when transitioning back to green. I learned as a small child riding with adults that you could anticipate the green light by observing the orthogonal lights' yellows, but if you're at a red here, don't expect any help, the green will just pounce upon you with no warning.
I've never heard of FSM, I'd watch a second video on this topic
Where do you have "Red-Amber" before green? In the U.S. it's just green -> Amber, then Red (and back to green).
In Europe. It helps the driver know which way the traffic light will go next. If you see just amber then you know red is next.
Same for Canada, except Quebec of course, where amber is just a decoration. No need for red-amber, red-green, or pink etc.
This man just headfakes us all into compiler design, and it's beautiful!
Sorry, Gary get gets close to, but not quite there. Sure, if you have had a course in compiler design, you already know this - however, if you haven't had such a course then I suspect making the connection is rather difficult.
@@RobertBartlettBaron You have a point that it's not quite there, but to be fair (and pardon me if this is very apparent, but) if he'd be explaining compiler design, then the video would've been named "Compiler design".
Not making the connection is fine. These are soft-skills that will come to the surface whenever people do decide to take a course in compiler design, and subsequently, they'll pick up on the intricacies much better. RIght now it's handily packaged in an entertaining video, and the knowledge will hang around until it's needed. (insert witty reference to interrupt handling)
But yeah, that's exactly why I called it a headfake. Gary makes us learn skills that are potentially useful in more than one field.
@@devjock I realize he is not explaining compiler design (see the original post for context), but he also doesn't mention the relationships between regular expressions and finite state machines, nor does he mention common applications that they are used in.
*GARY!!!*
Good evening Professor!
Good evening fellow classmates!
Stay safe out there everyone!!!
MARK!
Honestly, everything. Please do a series on FSMs!
Sadly this video didn't get many views so I won't be doing another FSM video soon. 😢
@@GaryExplains I looked at the views after commenting, I figured that would be your answer. But if it makes you feel happy, this video helped me more than any other in this year.
@@GaryExplains Actually, what I really wanted is a series on practical yet very simple applications for each design pattern.
Excellent video, thx. Can you please include a link to your github site for this?
Awesome! Reminds me of railroad diagram
Great explanation. Really inspiring, actually. Thanks!
Glad it was helpful!
Game AI state machine would be good and more computer science topics welcome. Thank for the good clear explanation of a potentially confusing topic.
Hi Gary. I was a bit surprised that you made a video about FSMs, but as a programmer I really enjoyed it, and I think you explained it very well.
(btw I also enjoyed the videos you made a while ago about writing a "software CPU")
I'd like to see more videos about FSMs, in C (which I know but I find the subject interesting) and Rust (which I barely know, and am curious about).
I think a video about FSMs for Game AI in Python would be very interesting as well.
I am glad you enjoyed it. Thanks for the feedback about future videos. One question, if I may, why were you surprised that I made a video about FSMs?
@@GaryExplains I was surprised because I've mostly seen videos about hardware stuff (which I also like) on your channel lately. Even though there has been programming videos before, of course. But it was a pleasant surprise :)
@@CedLePingouin Understood. Thanks. Yes programming videos are also part of my repertoire. I have videos on C, Rust, Python, linked lists, sorting, and more.
Yes please do a video on FSM using GO... THANK YOU!
I think finite state machines are very important in device firmware thus showing one written in C for the audience would be beneficiary.
Hey Gary, In few days I will have an exam for digital system and I'm revising for fsm and can't believe you uploaded this video. Thank you. Will watch this to understand it better.
Best of luck!
Would like if you did a some videos or a series on FSM for AI using python. If you could also explain some Graph Search Algorithms like RBFS in that series then that would be great
C or Rust examples would be amazing!
I published the C one already 👍
@@GaryExplains oh, I guess I missed the notification. I'll look for it! Thanks to RUclips's stupid recommendations, now I have too many channels with notifications enabled :(
It would be nice to have future videos on context free grammars and Chomsky hierarchy!
Thank you!
You're welcome!
FSM in C and comparing to Python for a simple example would be usefull. Having written many large and complex progams running on MCU's without FSM's it would be good to know the best preactice process / steps for using FSM's.
Hi garry thanks for this topic was wondering for a video where how regular expression are implemented. Not how to use matcher in java or c rather how to write own regular expression matcher logic .
Would love to see this in C as well
Python FSM for Game AI. That would be awesome.
What a timing! I just started Cpython internals book which talks about Finite State Automaton very briefly. You video made it much more clear. Thanks Gary
Thank you! Python, Control logic?? Keep it coming :-)
More please!
Fsm is everything
I´m learning Python so I would love more videos using it
We want to see similar in C. If it for FSM for protocol will be great
I published the C FSM video already! 👍
Thanks Gary! I cannot find the code on github :(
A Google search for "Gary explains GitHub" should be sufficient. Here is the link github.com/garyexplains/examples/tree/master/FSM
Interesting!
More is good
😄
The thumbnail seems to indicate a relationship between finite state machines and indexable fingers. I wanted to know about that.
More Videos on CS topics please. And in python
The "-1."or such as "`123." are valid. In fact, Python *does* accept these as valid.
Second thought, I don't think a person who wasn't interested in this topic would watch the whole video and then comments after, they'd just move onto something else.
yes MORE
I have used this for probably ALL my working life, wasn't called FSM though it was called Logic. Initially Relay Logic then Solid State Logic, then PDP8 then PLC(Ladder or CSF) and then Computer directly. Then retirement. I have drawn a State Machine for a Client but only after the fact. The Loop Back was illustrated by a on the connecting line btw.
Problem with basic State Machines is that they insist upon only a single change in State whereas my field of Machine Control often requires multiple Branching and coming back together. That requires passing to another State Machine (not sure why 'Finite' in there), not sure at this moment how you would comeback together.
I preferred roughing out a program using a sort of pseudo 'C' in which what you are showing would probably be a 'Case' statement. I am almost twenty years out of date now and certainly not 'Current' and Python has come along during that time and do not like it very much. Try a version of 'C' or Assembler (my preferred) and by inference the Arduino version of 'C'.
The machines I wrote Control for could quite happily mangle you or more importantly the Operator very badly so this is not a flippant subject for me.
Ladder logic is used to implement state machines. Sometimes many simultaneous state machines. Ladder Logic also deals with analog signals pretty well, whereas most FSM you're going to see written in Python will be dealing with far less complex "real world" situations, since the beginner is not really ready to deal with hysteresis, feedback loops, and process control timing, where a difference of 0.0002 seconds (200 microseconds) might be the difference of diverting a bottle on a conveyer that failed visual inspection into a reject bin or kicking the bottle so hard that it smashes on the wall (or hits a factory worker if you're very unlucky). I have great respect for PLCs, Logix controllers, and other such devices, and for the people who program them well.
I studied various forms of state machines in college, did some embedded programming and compiler development in various jobs after college, and over the years, most of my significant work involved extensive use of state machines. It was about 20 years after I graduated from college that I first started working with PLCs, but I picked it up pretty quickly. Still, it took me a while so that my code could compensate for cranky pneumatic actuators that changed performance significantly from when the bottle inspector was turned on to about 15 minutes of running once the rubber pressure hoses had stopped softening.
The reason they're called "Finite" is because there are a countable number of defined states the state machine can be in. There are many kinds of FSMs, ranging from simple accepting automata which have a single "start" state and have terminal states, and really don't branch a lot, but there are much more complex FSM. Often, it is easier to create multiple linked state machines, each having its own independent state, but with synchronization points where they can affect one another. Deterministic Finite Autonoma (DFAs) are predictable and will always behave the same for a given set of inputs, but there are other kinds that, although the state transitions are well defined, the outcome for a given set of inputs can be different based on some external influence such as a random number generator. There are push-down autonoma that have a state stack (Turing machines), "Finite State Machines with Oracle" that depend on an external process to determine state changes, and so on. Regular Expressions are "Accepting Finite State Machines", and are good for parsing serial input data.
My typical FSM for power sequencing of a circuit board defines each state in terms of the entry conditions, a list of actions to take on entry to the state (handled by an "enter state" procedure), a list of exit conditions each with the state that condition causes transition to, and an "evaluate" procedure that is called or event (timer, interrupt, etc.) handling, and in which the exit conditions are evaluated and the exit handling and transition to the next state is signaled when a matching condition is found. In C or Assembly, all states are represented as 'structs' that have function pointers for the "enter state" and "evaluate" entries (some also have a "reset" function pointer), and the FSM is driven by an outer "super-loop" that may run multiple parallel FSMs for different purposes (eg, asynchronous communication, watchdogs, key decode, A/D, etc.). What I do is often safety and time critical, and frankly, a "switch" statement isn't going to cut it. I always start out with a directed graph of the states, labeling all of the edges with the conditions under which the that edge is followed. A lot of analysis gets done on the graph before the first line of C code is written, though typically, the graph gets modified as the interactions between the FSM implementation and the hardware it runs in become better understood. After burning out a few $800.00+ FPGAs, you learn to be very careful about FSM design.
Many real-world FSM are most easily documented as a set of macro-states which are each smaller FSM made of of "micro-states". In these cases, rather than having a lot of parallel FSM that interact, you can think of it as either a birds-eye-view of a single gigantic FSM or an FSM made of "black box" states that are much simpler than the top-level FSM in which they exist. I'd much rather do formal documentation for 16 FSM each with around 10 states than one FSM with 160 states.
That is a lot of information and I wxpect I know most of the things you are referring to by different descriptions. I am not comfortable with expressive abbreviations and those things which sound cute as well so I just use them as is.
I do not prefer Ladder Logic if there is a choice. Seimens PLC, which I used often had a Logic Block Form and a sort of Assembler form They called them Control Flow System (CFS) and Statement List (STL) which were far more flexible and "Leaner". The last version I used almost twenty years ago, S7 could even be considered Object Type with a bit of imagination using local and global variables very nicely. I do not recall a State Machine type of function. I created Step Functions (the design is within their literature) with Set/Reset blocks formed into Sequence Steps with the time critical stuff going off in dedicated modules and in the background. I do not believe that you can get a meaningful timer of less than a tenth, maybe 0.05 with a PLC without very careful program layout because of the Scan Time Issue. The last time I added a scan time indicator into a program (using an S5-115 generation unit at the basic end of the range) where I was concerned about reaction time and wanted to check before I decided to use an expensive interupt type module it was about 15ms and I only need 30ms so I stayed with the cheaper solution. Processors are much faster nowadays up from 4.77MHz to lots of GHz now so I expect that PLC have speeded up too. My current knowledge of the subject remains the same as twenty years ago, not kept up-to-date.
I will read your reply again more carefully. It was interesting.
I would like to see this applied in C!
Who is stopping you from doing that ?
It's already in C and its 1000x easier. Just use switch statements.
@@ChandrapalSd Nothing, but I would like to see how Gary goes about coding it. Maybe I'd learn a thing or two!
Maybe more real world problems with fsm and then move onto the game?. Bcoz I feel like it would be too complex.
Wouldn't mind at all to do this in another language. Wait.. Norwegian? Just kidding. But my teacher was a stickler for grammar as we did something like this on the BBC Micro and Turbo Pascal at the end of the 80s. We had bespoke norwegian made machines with around 220 Kb, the odd memory was for some graphics indeed.
Python FSM game please!
RUST please.
"sad puppy state" - that's where I live!
Hey Gary please just keep on using Python! 😁👍🏼
FSM in C, please! Great video, thanks!
Part-time traffic lights (they do exist) have an end.
yes AI + FSM + Python
Python games AI please
ZOV
Imagine using python for fsm lol. The absolute state of python. They're regretting not having switch cases. You don't need to think with swtch-cases
Hmmm. I don't see how a switch statement helps. A dictionary is much more elegant.
@@GaryExplains
It's much easier to do:
switch(state) {
case 0:
(do something here)
state=1;
case 1:
(do something else here)
state=nth;
case nth:
...
default:
printf("I'm done.");
break;
}
Than to do all that python stuff. Enums make it much better. Python seriously needs switch statements. They just jump to a point in memory rather than check conditions.
@@chudchadanstud No, sorry, I don't agree. My Python code is just one line to know what handler to call to "do something". 1 line for 5 states and 1 line for 25 states, always 1 line. That case statement is hideous. Imagine if you had 50 states that would be a sprawling mess. Unreadable and unmaintainable.
@@chudchadanstud Also, the idea is to have a FSM that can be dynamically created, your switch statement is a hardcoded nightmare. Even in C you should be using a table of some kind.
@@GaryExplains Yes, you can work around it in many ways using, enums, abstract data structures, functions, pointers, OOP principals etc. It's also why I mentioned enums, with enums you don't have to use literals which will make tracking down things difficult just read the enum. An IDE can can track down every reference of an enum or auto complete. Order in the switchs statement matters less. It's also not a string so you'll notice typos before hitting compile.
This is so confusing!
Python FSM game please!