The speed differences don't surprise me. The formatting differences would surprise me. I don't think it is a hardware issue.
Sent from my iPod - excuse terseness and typos. - joey On Aug 9, 2009, at 23:12, Roger Hui <[email protected]> wrote: >>> Surely it isn't AMD versus Intel thing. >> >> You would be (but should not be) surprised. > > For instance: > > On an Intel Core2 Duo: > > x=: 1e6 ?...@$ 0 > y=: _. (1e3 ?...@$ 1e6)}x > timer=: 6!:2 > 10 timer '+/x' > 0.00195941 > 10 timer '+/y' > 0.139294 > > On an AMD Athlon 64: > > 10 timer '+/x' > 0.00268744 > 10 timer '+/y' > 0.00268972 > > That is, on the Intel there is a factor of 70 slow-down > on floating point summation if you have NaN sprinkled > in your vector. On the AMD, there isn't. > > > > ----- Original Message ----- > From: Roger Hui <[email protected]> > Date: Sunday, August 9, 2009 21:18 > Subject: Re: [Jgeneral] Array Based Languages > To: General forum <[email protected]> > >>> Surely it isn't AMD versus Intel thing. >> >> You would be (but should not be) surprised. >> >>> I suppose I can count this as another reason I'm happy I don't >>> use Windows.... >> >> We shouldn't blame this on Windows. Instead, >> we should eschew printf() and write our own >> formatting routine. >> >> >> >> ----- Original Message ----- >> From: Joey K Tuttle <[email protected]> >> Date: Sunday, August 9, 2009 19:32 >> Subject: Re: [Jgeneral] Array Based Languages >> To: General forum <[email protected]> >> >>> At 13:36 -0700 2009/08/09, Roger Hui wrote: >>>> J uses the C printf() routine to format 64-bit floating point >>>> numbers. The different outputs are perhaps due to the >>>> differences in the printf()'s on the different systems. >>>> In any case, only the first 16 decimal digits are significant; >>>> the rest are garbage. >>>> >>> >>> "the rest are garbage." seems a little harsh. Especially in >> the >>> case >>> of numbers that can be represented exactly in 64-bit floating >>> point >>> e.g. >>> >>> 40":"0 ]2^120+4*i.5 >>> NB. 64 bit floats >>> 1329227995784915872903807060280344576 >>> 21267647932558653966460912964485513216 >>> 340282366920938463463374607431768211456 >>> 5444517870735015415413993718908291383296 >>> **************************************** >>> >>> which is identical on my systems to - >>> >>> 40":"0 ]2^120+4*i.5x >>> NB. extended integers >>> 1329227995784915872903807060280344576 >>> 21267647932558653966460912964485513216 >>> 340282366920938463463374607431768211456 >>> 5444517870735015415413993718908291383296 >>> **************************************** >>> >>> versus >>> >>> 40":"0 ]2^120+4*i.5 >>> 1329227995784915900000000000000000000 >>> 21267647932558654000000000000000000000 >>> 340282366920938460000000000000000000000 >>> 5444517870735015400000000000000000000000 >>> **************************************** >>> >>> Somehow the 0s look more like garbage than the digits in the >>> first >>> two. Since your other examples show the 0s, I'm assuming it is >> a >>> Windows issue since my environments are Linux and Darwin. >> Surely >>> it >>> isn't AMD versus Intel thing. >>> >>> I guess the "logic" in choosing the final 1 in the formatted >> pi >>> is >>> that it is in the center of a sort of "guard band" - >>> >>> 3.14159265358979310 - 3.14159265358979280 >>> 3.14159265358979290 >>> 3.14159265358979300 3.14159265358979310 3.14159265358979320 >>> 3.14159265358979330 3.14159265358979340 NB. single long >>> line will >>> undoubtedly be munged by mail... >>> 4.44089e_16 0 0 0 0 0 _4.44089e_16 >>> >>> >>> (j.15+i.5)":"0 o.1 >>> 3.141592653589793 >>> 3.1415926535897931 >>> 3.14159265358979312 >>> 3.141592653589793116 >>> 3.1415926535897931160 >>> >>> Certainly the last 1 in the default format of 0.1 is garbage >>> since it >>> should be a 2 - >>> >>> (j.15+i.5)":"0 pi 20 >>> 3.141592653589793 >>> 3.1415926535897932 >>> 3.14159265358979324 >>> 3.141592653589793238 >>> 3.1415926535897932385 >>> >>> I suppose I can count this as another reason I'm happy I don't >>> use Windows.... > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
