You can use , in the verb argument to / if you want to accumulate a
sequence of results. And you can use {. on the right argument to that
verb if you want the most recent of those results. (The rightmost noun
in the original sequence effectively being the first "example
result".)FYI, -- Raul On Tue, Feb 20, 2018 at 11:03 AM, Arnab Chakraborty <arnab...@gmail.com> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
