Sometimes the interpreter executes a verb twice on an operand - usually when two different executions returned different shapes/types and it's easier to reexecute than to use the previous result.
This means that if you have a verb that has a side effect (for example, it issues an order to buy stock) you really need to make sure that its results are consistent. Roger told me privately that u"n is guaranteed not to execute u more than is necessary. There seems to be no guarantee of sequential execution, and you never know when multi-core operation might be implemented. I think that the language should be augmented to have some adverb that guarantees sequential execution. It is true that I advised against for. loops. I stick with that advice for beginners. The full advice would be 'avoid for. loops unless they are the best solution' but beginners wouldn't be able to find better implicit loops easily and would end up writing for. rather than learning how to deal with arrays. When the body of a loop does a lot of work there is no reason to avoid for. . Henry Rich On 3/14/2011 9:30 AM, Robert O'Boyle wrote: > Hi > > When I was first got into J, I found the following statement in Chapter 6 of > J for C at > file:///C:/j602/help/jforc/loopless_code_i_verbs_have_r.htm#_Toc191734341 > > Order of Execution in Implied Loops > > Whenever a verb is applied to an operand whose rank is higher than > the verb's rank, an implied loop is created, as we have discussed above. > The order in which the verb is applied to the cells is undefined. The > order used on one machine may not be that used on another one, and the > ordering may not be predictable at all. If your verb has side > effects, you > must insure that they do not depend on the order of execution. > > Current versions of the interpreter apply the verb to cells in > order, but that may change in future releases. > > I also read in either J for C or LJ that one should avoid control structures > (for, while, etc) as much as possible due to the performance penalty. This > put me in quite a bind re much of my work which is temporally based. So I > have generally used rank to do much of my looping (thus my recent query) but > always being wary of potential issues in future J versions. It would be good > for J to clarify all this. > > Bob > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Raul Miller > Sent: March 14, 2011 9:28 AM > To: Programming forum > Cc: Zsbán Ambrus > Subject: Re: [Jprogramming] Recursive algorithm > > On Mon, Mar 14, 2011 at 7:15 AM, Zsbán Ambrus<[email protected]> wrote: >> (For loops could have the advantage that I think jsoftware has made >> some vague statements on the mailing lists that if you use the rank >> operator on verbs with side effects, it might not always call the verb >> as many times or in the right order in some case of optimizations in >> future versions. This is belivable because (u/\. y) already does such >> an optimization, and in fact I think that's a right idea.) > > I do not recall any official statement of that nature, *ever*. > > I believe that that is "folk wisdom" based on experience with other > languages. > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
