From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-09-04 03:09:09
Thomas Xkey <xkey <at> yahoo.com> writes:
> 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
> (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
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
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
> 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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk