Author Message

Quote:
> State machine transition is easily expressible in J, using ({ {&M),
> where M is the transition matrix.  For example:

> or

> (start is the starting state -- a row index into M [typically a simple
> scalar], and M is typically a matrix of states (row indices into M)).
> APL*PLUS/III (or whatever it's called) doesn't provide an easy way of
> doing this (you must expose the internal guts of the machine to the
> global name space) unless you use CASE.  So, CASE is a way of getting
> around the problems of representing constant data in functions.

End {<-} 1{disclose} APPLY_TRANS /({transpose}transitions),start,{enclose}M

Where you define:
{del}R{<-}trans APPLY_TRANS fsm;state
:if 2>{depth} fsm {rem} or some other suitable test... I can see other possibles.
R {<-} trans fsm
:else
(state fsm) {<-} fsm
R {<-} (fsm[state;trans]) fsm
:end
{del}

I would leave it to others to debate the "easiness" of the above, but
there is no need to expose any guts to any space, any more than in
the J solution.

Later...
---------------------------------------------------------------------
|\/| Randy A MacDonald       |"You just ASK them?"

BSc(Math) UNBF '83      | APL: If you can say it, it's done..
------------------------------------------------------------< gnat )-

Fri, 21 Mar 1997 15:04:23 GMT
Randy A MacDonald:
. End {<-} 1{disclose} APPLY_TRANS /({transpose}transitions),start,{enclose}M
.
. Where you define:
.  {del}R{<-}trans APPLY_TRANS fsm;state
.   :if 2>{depth} fsm {rem} or some other suitable test... I can see other possibles.
.       R {<-} trans fsm
.   :else
.      (state fsm) {<-} fsm
.       R {<-} (fsm[state;trans]) fsm
.   :end
.  {del}
.
. I would leave it to others to debate the "easiness" of the above,
. but there is no need to expose any guts to any space, any more than
. in the J solution.

Grump 1: APPLY_TRANS must be globally defined.
Grump 2: I find the J syntax more elegant
Grump 3: APPLY_TRANS has a lot of the kind of overhead that I try and
avoid. Specifically, packing and unpacking arguments at each
stage of a light weight iterative process.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

NB.  public e, n, y
x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q

Sun, 23 Mar 1997 06:00:07 GMT
Raul DelUth MIllEr:

Quote:
> APL*PLUS/III (or whatever it's called) doesn't provide an easy way of
> doing this (you must expose the internal guts of the machine to the
> global name space) unless you use CASE.
> Grump 1: APPLY_TRANS must be globally defined.

Excuse me, but APPLY_TRANS did not strike me as "the guts of the
machine" that you were so concerned about exposing to the global
name space.

I hope you are not one of those "problem tricklers" who engage in the following
dialogue:
You: This thing X has problem A
Me: This thing Y solves problem A;
You: When I said A, I really meant (unrelated) B.

Furthermore, APL will not solve all your problems; sometimes you actually have
to write code. Perhaps a problem with a lot of users of APL is they want things to

personally think that these J constructs deserve higher priority for inclusion in
mainstream APL's than all this control structure stuff... Dyalog already has a sort

I have to write:

{del}R{<-}twoplus X
[1]  R{<-}2+X
{del}

So I write it, and I get on to the real problems.

Of course, i've defined a verb "of" so that I can write:

R {<-}  '2+{omega}' of X

and I don't need to clutter the WS with the m{*filter*}equivalent of  "sum"

Quote:
> Grump 2: I find the J syntax more elegant

Of course, but what's your point.  Use J.  Call Chris at Strand and get a copy.
7734, I thought up the "of" verb because of J, with a little help from direct def-
inition.

Quote:
> Grump 3: APPLY_TRANS has a lot of the kind of overhead that I try and
>          avoid. Specifically, packing and unpacking arguments at each
>          stage of a light weight iterative process.

Now you're just whining at a problem that does not exist, or shouldn't exist:

(X Y) {<-} Z

doesn't strike me as "overhead" or at least the kind that should be complained about.
In fact I would venture that the array indexing, or even the { usage, uses more cycles
than stranding does.

Actually, by restructuring the argument to APPLY_TRANS, you can do this:

End {<-} 1{disclose} APPLY_TRANS /({transpose}transitions),(start M)

Where you define:
{del}fsm{<-}trans APPLY_TRANS fsm
(1{disclose}fsm) {<-} ((2{disclose}fsm)[(1{disclose}fsm;trans])
{del}

and you've removed the :if.

Later...
---------------------------------------------------------------------
|\/| Randy A MacDonald       |"You just ASK them?"

BSc(Math) UNBF '83      | APL: If you can say it, it's done.
Natural Born APL'er     |
------------------------------------------------------------{ gnat }-

Mon, 24 Mar 1997 03:41:19 GMT
Re: state machine transitions

Perhaps I don't fully understand the question, or I'm just restating what
has already been said, but isn't this just

(M GSM)/Transitions,Start

` State<- Tran (Machine GSM) State
[1] State<- Machine[State;Tran]

where GSM is a "General State Machine" operator (and Transitions is right to
left)?  I realize APL*PLUS III doesn't have defined operators, so try

` foo; &GSM          o} & is delta
[1] &GSM<- M
[2] GSM/Transitions,Start

` State<- Tran GSM State
[1] State<- &GSM[State;Tran]

where &GSM is an unbound variable in GSM.  It is NOT a global variable--
to call GSM one would first _localize_ &GSM, assign M to it, make the call,
then erase &GSM.  This is an example where dynamic scoping is actually useful;
in order to effect a temporary "state" change (or initialization) one simply
localizes the relevant variables (only).  It works quite well for "utility"
type functions (such as pretty-print).

(Or do what Randy MacDonald suggests, carry M along as part of a structure.)

One "interesting" way to do this kind of thing is to simulate parallel-prefix

` SV<- SV2 GSM SV1   o} state-vectors
[1] SV<- SV2[SV1]

which can be executed on a parallel machine in logarithmic time because GSM is
now "associative".  Whether this is efficient on a serial machine depends on
the size of M and whether one can express it using the indexing primitive...

Mon, 24 Mar 1997 01:31:39 GMT

 Page 1 of 1 [ 4 post ]

Relevant Pages