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 <k...@math.uh.edu>
To: "programm...@jsoftware.com" <programm...@jsoftware.com>
Subject: Re: [Jprogramming] applying >1 gerunds to a set of items
Message-ID: <eb35aa7d-a7d9-4f51-b885-624b78c52...@math.uh.edu>
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
