Thomas Xkey <xkey <at> yahoo.com> writes:
fsm
This library seems & acts more like a "simulator" than an "efficient finite state machine".
I'm wondering if this post is more like a troll... But I'll bite.
It doesn't seem to scale well even according to the author(s)? (most fsms a computer scientist would deal with encompass 100s to 1000s of states with as many different transitions possible)
Not being a computer scientist, I can only assume your generalisation doesn't apply to anything that I've done with fsms. Or do you just mean that the computer scientists use telephones like the rest of us? I haven't tried to implement an fsm with 1000s of states as a single program/module, using boost fsm or anything else. 1000s of transitions is quite reasonable though. I shouldn't think boost fsm would have any particular problem with this.
I would strongly urge something more efficient and bare bones along the lines of http://www.research.att.com/sw/tools/fsm/
Interesting. If that is where you are coming from, I can only agree that boost fsm is not a good tool for eg. NLSR (mind you, I've seen at least one pretty awful tool for that). Conversely, the AT&T fsm tools look to be quite unsuitable for some other applications, and to be focused on the construction and manipulation of fsms for language processing (or other similar recognition problems). There is nothing wrong with that, but it does happen to be completely useless for a project I have jsut been using boost fsm on. There is room for both.
take on the mantle of an "fsm" library in boost upon which coarse-grained objects can be simulated from above.
I don't understand why you think boost fsm is for simulation. I can imagine using it for that (although being a compiled fsm, I'd suggest that would not be a common use) but it certainly has use beyond that.
would prefer this 'currently proposed' fsm to take on its true stance perhaps attaching the nomenclature of "hlfsm" --> "high level fsm". Due to its greater abstractions, fluffy aggregations and bulk in nature it isnt "efficient". If a library isnt efficient for its purpose or intended purposes then it will be under-utilized. I could never use this one as it is evolving away from an efficient fsm into more of a large coarse simulator. [now if i had need of that it would be great]
I don't know what, if anything Andreas intends to add to boost fsm, but I don't see it evolving towards anything bigger - it seems to be complete, given its objectives.
This library seems more intended for simulation at a higher level than at a more simplistic state/event transition approach.
I wouldn't want to force a real computer scientist to confront the possibility that there might actually be real things that are controlled, not simulated, by fsms but - um - there are. If all you want to do with an fsm is to use it as a recogniser taking some lightweight symbol representation as input and processing it until a final state is reached, boost fsm is probably the wrong tool. I am reasonably sure that trying to make one tool, or a shared component, do everything that can be done with fsms is not going to produce the desired/required efficiency.
Yes i am biased coming from an algorithms and mathematical background; I am more of a computer scientist who practices softare engineering than most application programmers who just want a product out the door and efficiency goes out the window.
What class of problem do you think "most application programmers" will apply boost fsm to, which will result in rampant inefficiency? In my experience, those of whom you speak are more likely to write thousands of lines of spaghetti, storing pieces of state in assorted knooks and crannies, rather than using anything as "inefficent" as boost fsm ;-) There is also the class of problem that is more likely to be addressed by boost regex or xpressive - in fact, I'm wondering if xpressive isn't somewhat closer to what you are looking for?
Can we adjust this library conceptually into a cleaner bare-bones fsm at one layer and then interject the higher level simulation aspects along with the ability to automatically produce code etc.
I don't see how to do this (assuming I'm understanding what you are calling "simulation aspects") - do you?
[Canned automatically generated code is usually not so hot.
In fact it rather bites. Any decent programmer can still out-optimize todays compilers based on intimate knowledge of their code & algorithms even on todays complex processors.
What canned code? The transition logic? The whole fsm library? I don't follow your point here at all?
Given that compilers have thousands of man-years of code & know-how how does one expect this fsm library to generate decent code or is it intended for someone who cannot program?]
Does this rant mean that the whole fsm library is futile and that real prog^H^H^H^Hcomputer scientists write in assembler? Not a bad language choice if your entire app is an fsm I'll admit. Regards Darryl.