Henry wrote:
>  It's a different story if they tell you up front 
>  that they want the integer part of pi times 10^20.  

I like this explanation.

But even without such an intuitive argument, we could understand the
difference between  <.o.  and  <....@o.  by reading the appropriate parts of
the DoJ.  In this case, §II.G [1]:

        Various primitives produce extended results if the argument(s) are
extended. 
        Some verbs f produce floating point (inexact) results on some
extended 
        arguments because the result is not integral; however, <....@f and 
>....@f
produce 
        extended integer results when applied to extended integer arguments.


In other cases, you also have to look at Appendix B [2] to understand
non-functional aspects of code.

But there is a pattern to which code has these aspects, and which don't.
The rule is special code is always applied to function compositions (viz
<....@o. vs <.o.).  Sometimes those compositions are explicit and obvious, as
with <....@f (composition conjunctions), and sometimes they're implicit and
"invisible", as with f i. 1: (hooks and forks).

But special code will never apply to sequences of primitives like  <.o.  ,
and Henry's explanation gives us the rationale:  when verbs are composed, J
knows "all at once" or "beforehand" what you want to do.  When they're
sequenced like  <.o.  , J obediently executes them seriatim (one at a time,
in order).  In fact, J always applies a primitive or named entity to its
argument(s) as soon as it has them, which is precisely why special code is
only invoked by composed functions.  

In the case of composed functions, J "sees" the function composition before
the arguments to the functions (verbs), so it can do internal magic before
applying the result to the arguments.  Without any composition (explicit or
implicit), J must follow the rule of immediate execution, without looking at
"what comes next", so it doesn't get a chance to optimize the whole thing
(because "the whole thing" doesn't exist, in a sense).

And lest anyone get the wrong idea: J always follows the rule of immediate
execution.  Function composition isn't some kind of exception.  In fact,
composition is another example of immediate execution: the execution of an
conjunction against _its_ arguments, the verbs being composed.  It's just
that operators have higher precedence in J's grammar than verbs (to minimize
the need for parenthesization), so that J sees the composed function and can
optimize it before it ever sees the noun arguments to the composed (derived)
verb.

Hope this helps,

-Dan 

PS:  Maybe a concatenative language can optimize sequences of functions
before they're applied to arguments?

[1]  DoJ §II.G, Extended and Rational Arithmetic:
     http://www.jsoftware.com/help/dictionary/dictg.htm   

[2]   DoJ Appendix B, Special Code:
        http://www.jsoftware.com/help/dictionary/special.htm



----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to