Good code/bad code & looping 
Author Message
 Good code/bad code & looping



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  
 Good code/bad code & looping
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  
 Good code/bad code & looping
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  
 Good code/bad code & looping
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  
 
 [ 4 post ] 

 Relevant Pages 

1. Good code/bad code & looping

2. Good/Bad code

3. good code, bad hacks: what are the symptoms?

4. Anyone have a good coding style example for coding up FIR FILTER?(EASY METHOD)

5. Dylan coding style & best practices

6. P-code, T-code, and Uni-Code Intermediate Languages

7. P-code, T-code and Uni-Code Intermediate Languages

8. Example of Python code (C code to Python code)

9. good code/good language

10. Imaginary numbers & J: good news/bad news

11. ## Cadence: The Good, The Bad, & The Ugly ##

12. ## Cadence: The Good, The Bad, & The Ugly ##

 

 
Powered by phpBB® Forum Software