Hi Henry, Indeed when I wrote the verb
sm=.4 :'s=:s sf y ] s of y' I first wanted to write the verb so that sm/ 2 3 4 runs the machine on input 2 3 4. But I could not manage this, because I need to preserve the output from each cell, but only the final state. So I seem to need u/ and u/\. \both together. Any suggestion? On 20 Feb 2018 09:34, "Henry Rich" <henryhr...@gmail.com> wrote: The idiomatic way to pass state from execution on one cell to the execution on the next is with u/ or u/\., depending on whether you need the result from each cell or just the final result. You write |. u/\. (|. array) , initialvalue and u is repeatedly executed between (cell of y) and (previous result). If the amount of state passed between executions is large, this can be inefficient. The language could be enhanced by primitives that address this situation. Watch this space. Henry Rich On 2/19/2018 10:57 PM, Raul Miller wrote: > Hmm... I think you should view the state machine as a component in a > larger system. > > I say this because other languages tend to encourage you to push > functionality into loops [loops are a bit laborious and noisy to > write, so you tend to want to not write many of them], but that's not > always a good idea. > > So - for example - when using the ;: primitive, it can be entirely > reasonable to add preprocessing and/or postprocessing, if that makes > the job simpler. > > It can also be reasonable to use for loops (or sometimes even while > loops), or whatever else -- if my "state machine" needed a stack, I > think I'd be tempted to use a for loop (but note that if the stack is > simple enough it might be easier to represent stack depth using > addition and break out the "stack handling" into a separate > expression, like +/\-/'()'=/text for example). > > It can even be reasonable to use side effects to communicate > computational progress between (verb"0) invocations, like you are > doing here, but for whatever reason I usually shy away from that. > > That said, once I have a first draft implementation, that I can see, > test and understand, I sometimes I like to rewrite it (perhaps using > primitives instead of explicit loops). [And I should get in the habit > of doing performance tests when this gets multiple working versions - > but, all too often, unless performance problems make themselves known, > I pick based on other criteria, like which one looks simpler to me.] > > That's all that I can think of that might be relevant... > > Thanks, > > --- This email has been checked for viruses by AVG. http://www.avg.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
