The size of a is such that paging probably came into play, whence you can throw the timings out the window. (The timing difference between +/a and (+/)a really demonstrated that; there shouldn't be any difference betwween the two.) Moreover, unless you really are doing integers, floating point numbers give a more meaningful answer. Thus:
x=: 1e7 ?...@$ 100 100 ts '+/x' 0.0297878 1024 100 ts '(+/%#)x' 0.0166005 1216 100 ts '(+/)x' 0.0298247 1024 - No difference between +/x and (+/)x - +/x has some extra code to handle integer overflow; (+/ %#) x "knows" that the answer is floating point and doesn't have the integer overflow code. x=: 1e7 ?...@$ 0 100 ts '+/x' 0.0192155 1024 100 ts '(+/%#)x' 0.0191934 1216 100 ts '(+/)x' 0.0202687 1024 No difference among the three on a floating point argument. ----- Original Message ----- From: David Mitchell <[email protected]> Date: Wednesday, May 20, 2009 8:31 Subject: Re: [Jprogramming] +/ slower than (+/ % #)/ To: Programming forum <[email protected]> > bill lam wrote: > > On Wed, 20 May 2009, Steven Taylor wrote: > >> 6!:2 'b=.+/ a' > >> 0.240794 > >> 6!:2 '(+/ % #) a' > >> 0.13628 > > > > I think that 'a' is already cached when executed the tacit. > You can > > compare > > (100) 6!:2 'b=.+/ a' > > (100) 6!:2 '(+/ % #) a' > > > > Some fixed tests: > > a =: ? 100000000 $ 100 > (100) 6!:2 'b=.+/ a' > 0.441664432211 > (100) 6!:2 'b=.(+/ % #) a' > 0.24710853195 > (100) 6!:2 'b=.(+/) a' > 0.375218973361 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
