There can be significant overhead from repeated name look-ups because the interpreter cannot assume the value of a name is not changed in passes through an implied loop. I have sometimes used the adverb f. Fix on tacit "production code" to remove unnecessary look-ups.
Kip Murray Sent from my iPad On Jan 30, 2013, at 7:15 PM, Henry Rich <[email protected]> wrote: > There are two overheads: parsing and verb-start. > > verb-start is the time required to get a verb going: find operands, check > types, start the loops. > > Try bigoperand *:@+ bigoperand and compare it to > bigoperand *:@:+ bigoperand. The difference is the number of verb-starts. > > Henry Rich > > On 1/30/2013 6:49 PM, Graham Parkhouse wrote: >> Kip Murray wrote: >> >> Message: 6 >> Date: Fri, 25 Jan 2013 20:31:56 -0600 >> From: km <[email protected]> >> To: "[email protected]" <[email protected]> >> Subject: Re: [Jprogramming] applying >1 gerunds to a set of items >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=utf-8 >> >> Dan, most of the code in the z locale is explicit. What is the fundamental >> value of explicit code? >> >> ------------------------------- >> >> I have been studying Roger's Sudoku solver >> >> http://www.jsoftware.com/jwiki/Essays/Sudoku >> >> after attempting my own solver. Mine was going OK, on the very easy >> problems, but, even with guessing, it ground to a standstill on a supposedly >> not very difficult one. So, rather than soldier on I studied Roger's code, >> and learned a lot. His use of nub sieve (~:) to check the uniqueness of >> numbers within regions was beautiful. Now that I'm impressed by the >> usefulness of this primitive, I hope I shall use it appropriately in the >> future. >> >> It seems to me that Roger used tacit code where practicable. He used the >> rank conjunction judiciously. The 'main' function, sudoku, is a one-liner of >> immense beauty, embodying two mighty loops and comprehensive stack >> management in 11 words. By adding @ , to the end of the sentence he blocks >> the possibility of solving any number of Sudoku puzzles at once! Had he left >> them off, the right argument could have been a matrix of n problems, with >> shape n by 81. >> >> I have gleaned from this forum that it is generally better, efficiency-wise, >> for explicit verbs to have large rank. If the arguments have much higher >> rank than the verb, the frame is big, and the verb has to be interpreted >> many times each single time it is called. Am I right in thinking that this >> is not the case for tacit code? Doesn't the tacit code get interpreted once, >> when the script is loaded? If this is so there are many situations where >> tacit code is considerably quicker in execution than the equivalent explicit >> code. >> >> I was severely challenged by tacit code when I first moved to J from APL. I >> used to think in terms of nouns, visualising the characteristics of the data >> as it was transformed by each step of the calculation. I was happy to >> 'write' functions and give them names, but to have one-liner assignments to >> verbs instead of nouns as my preferred way of thinking, has taken years. >> Roger has a one-liner for the verb ok. My old mindset would reserve ok as >> the name for a noun, and it would be either 0 or 1! Notice how much more >> content there is in a verb ok that returns 0 or 1, content that doesn't vary >> with the data. >> >> Thank you, all, for the experience. >> >> Graham >> >> >> ---------------------------------------------------------------------- >> 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
