There are a couple of issues with the FSM domain that we would like to
comment on and make proposals for:
1) The "setAction" transition parameter does not really support ports
as destinations (contrary to what one would expect after reading
the code and class documentation) since there is no
transferOutputs() operation called after FSMDirector (and FSMActor)
is postfired (where CommitActions are executed). The PDF design
documentation is correct though about mentioning only Parameters as
destinations for the "setAction" (CommitAction class) attribute of
a transition.
2) In transition actions, we would often like to be able to:
- Perform a computation based on current inputs and current
parameters (state-variables),
- Produce output token(s) based on the result of the computation,
- Update some parameters as the result of the same computation.
Currently, one has to repeat the same computation twice, once in
"outputActions" and then again in "setActions" (or use a
refinement, see 3). There is no way of using a single statement list to
update state variables and produce outputs for a transition and at
the same time maintain consistency for domains with fixed-point
semantics.
3) The current way of using "setActions" to set the next state's
refinement parameters is not as intuitive and visible as the
(similar in intent) process of using relations that connect
refinement's output ports and FSMActor input ports to transfer
refinement output tokens to FSMActor action expression
variables. The user has to (repeatedly) enter setActions in all
states where (possibly the same) FSMActor parameter needs to be
exported to refinement(s).
Our proposals below would seem to eliminate the above issues and
eliminate the need have two different transition action classes. We
think that these improvements would simplify the use of the FSM domain
and better hide the fixed-point isses from the "end user".
We would also be interested in hearing any counter-arguments, or why
such an implementation was not pursued.
Proposal for 1 and 2
--------------------
In FSMActor, why not use the approach advocated by the Ptolemy design
document for designing actors to maintain state consistency in fixed-
point domains?
For the set of FSMActor parameters, create a corresponding "shadow"
set of parameters during preinitialize() and keep it updated as
parameters are added / removed.
When transition actions are executed (during fire() only, no need for
two different types), the destination (left hand side of assignment)
is the shadowed parameter, all references in the expression (right
hand side) use current parameter values. Hence there is no state change
during repeated firings in fixed-point domains.
During postfire(), the shadowed parameter set (already evaluated) is
copied to the current parameter set. Parameter values that were not
updated are handled by copying current values to shadowed ones during
prefire().
To support common "subexpressions" for state updates and output, a
"temporary" marker is used for variables that are evaluated, but don't
preserve values after the action is executed. These are not
shadowed. The values of such variables is available to expressions
in commands that follow. This makes the reasonable assumption of
left to right, sequential evaluation of the action statement list.
Proposal for 3
--------------
In FSMDirector, during fire(), just before the refinements prefire()
is called, iterate through FSMActors output ports and check whether a
port is connected to a containers output port or to another actors
(refinement) input. For FSMActor ports connected to the current
refinements inputs, if a state variable exists with the same name,
transfer the variable token to the refinements input according to the
current connection map (similarly to
FSMActor._setInputsFromRefinement()).
This would make the process of exporting state variables to
refinements more visible in the gui using the standard PtolemyII
entity/relation topology.
Thank you and regards,
Zoltan Kemenczy
Sean Simmons
Research in Motion Limited,
Waterloo, Ontario Canada
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
