> > 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
