On Wed, Jan 30, 2013 at 6:49 PM, Graham Parkhouse <[email protected]> wrote: > 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.
It's generally the case, with J primitives, that each one does a significant amount of work each time it's executed. And, if you can give them large chunks of data to chew on, that overhead would be amortized in terms of cost per unit data. However, in this case, Roger is constructing an n by 81 array, where n depends on the puzzle in question and the stage of processing for the puzzle. And, there's good reasons for that. (If you had heard and agreed with some marketing-style statements made about sudoku puzzles you might believe that this is unnecessary, however there have been some officially published puzzles where the solution cannot adequately be represented without this approach -- they were ambiguous and had multiple solutions.) So, anyways, in this case there's good data-integrity reasons to limit the solver to considering only one puzzle at a time. (To deal with multiple puzzles you'd wind up needing to box the arrays representing each puzzle, and that already works with this approach.) > 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. Visualizing the nouns is a good practice, I think. I do not think you should be critical of yourself for that. > 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. Personally, I like being able to understand verbs in terms of "what they do to nouns". But I agree that it's also worthwhile being able to have abstract concepts of how they work. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
