DFA illustration...

[Don Y]

On 9/10/2022 7:16 PM, Clifford Heath wrote:

On 10/9/22 15:44, Don Y wrote:

Returning to your suggestion (libfsm), I didn\'t see anything that
indicated support for this sort of \"annotation\". Or, even suggestions
of where it *might* put it. But, I\'ll have a look at it, tonight.

Jeez Don, if you want to know how to use Graphvis, you should just read the
flaming documentation, not write an epistle here. It\'s not perfect, but it\'s
worth at least looking at before you start complaining about it.

I didn\'t complain about the tool. Rather, pointed out that I don\'t
know *where* in the visual representation of the machine to add
these annotations. There have been efforts to augment state diagrams
with indications of certain common mechanisms (e.g., timers) but
nothing that seems to have taken hold as a \"common practice\".

I was asking about experiences drawing state diagrams, not tools
to do so.

 

[server]

On Thu, 8 Sep 2022 16:10:01 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

In practical terms, one augments each transition with an
\"action\" associated with the input(s) being acted upon.

In my software implementations, I employ several hacks
to increase efficiency and range of expression possible
in a given machine. (not worth explaining, here)

In an example I\'m presently working, it would really be nice
to annotate the graphic representations of the machines with
some of these \"hacks\". But, they aren\'t consistent with
traditional DFA illustration practices (nor are the explicit
action annotations!) so I\'m at a loss as to an *intuitive*
means of annotation. Something that an observer unfamiliar
with the mechanism could easily infer without needing a legend!

Chief among these, I impose (optional) \"on entry\" and \"on exit\"
actions for each state. This is a shorthand to avoid having to add
those actions to every transition entering -- or exiting -- the
state.

So, every transition entering the \"OFF\" state need not explicitly
\"remove_power()\" if an \"on entry\" action declared that action for
the OFF state. Otherwise, any transition arriving at OFF failing
to do so could result in the machine being in the OFF state without
having already *removed* power.

Likewise, every transition leaving the OFF state (presumably for some
\"non-OFF\" state) can be assured to \"apply_power()\" by the specification
of that as an \"on exit\" action for the OFF state.

DFA illustrations quickly become cluttered (esp if inputs are named
symbolically) so any mechanism has to be relatively \"tight\"...

What is DFA?