[boost] Re: my 2 cents - fsm

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-09-04 03:09:09

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.