>/y is not good because your faithful implementer knows that it can be done without examining every byte. You can also detect that from the following experiments:
6!:2 '>/y' [ y=: 1e6 [EMAIL PROTECTED] 2 3.93905e_5 6!:2 '>/y' [ y=: 1e7 [EMAIL PROTECTED] 2 3.26857e_5 6!:2 '>/y' [ y=: 1e8 [EMAIL PROTECTED] 2 2.87746e_5 No way on earth it could give timings like that if it examined every byte. > actually +/y for ints with float result is faster CPB > (8*#q) %~ 2.8e9 * 6!:2 '+/q' > 0.857189 > datatype +/q > floating The factor is actually 4*#q rather than 8*#q. It's not the datatype that matters but the number of bytes in the arguments or the result, which ever is larger. And q has way larger number of bytes than +/q, and the number of bytes in q is 4*#q. To repeat: Try +/boolean , not calibrated. ----- Original Message ----- From: Oleg Kobchenko <[EMAIL PROTECTED]> Date: Friday, December 22, 2006 2:09 pm Subject: Re: [Jprogramming] Cycles per Byte > I don't know why >/y is not good. > If the value changes by changing either last > of first item, it should involve every byte. > > Next closest > > [EMAIL PROTECTED] > > (4*#q) %~ 2.8e9 * 6!:2 '>./q' NB. raw > 1.57819 > > actually +/y for ints with float result is faster CPB > (8*#q) %~ 2.8e9 * 6!:2 '+/q' > 0.857189 > datatype +/q > floating > > Compare > [EMAIL PROTECTED] > (4*#r) %~ 2.8e9 * 6!:2 '+/r' > 1.6156 > p=. 1e7#0.5 > (8*#p) %~ 2.8e9 * 6!:2 '+/p' > 1.40882 > > > --- Roger Hui <[EMAIL PROTECTED]> wrote: > > > Similar reply as for +./y . And calibration gives > > wrong answer. > > > > Try +/boolean , not calibrated. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
