References: Message-ID: <02c401c42dee$5084bfc0$60c15718@lap> Date: Thu, 29 Apr 2004 06:31:41 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM Thanks for doing the benchmark. I conjecture that the performance of _ has gotten worse from the Pentium III (my 500 Mhz machine) to the Pentium IV (your 2 Ghz machine): no _ _ P3 0.882357 2.06805 P4 0.327353 5.66807 As I said, I am not worried about the timings on *, because the overwhelming majority of cases will not involve infinity, and those cases are fast. ----- Original Message ----- From: "Richard Donovan" To: Sent: Thursday, April 29, 2004 1:05 AM Subject: Re: [Jforum] Optimization of */ OK here they are... timer =: 6!:2 timer 'x*x' [x=: 1e7 $ _ 5.66807 timer 'x*x' [ x=: 1e7 ?@$ 0 0.327353 ======================================================================== Message-ID: <02fd01c42df4$383edad0$60c15718@lap> Date: Thu, 29 Apr 2004 07:13:34 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM Can members of the forum please run the following benchmarks involving * and _ on various systems, and report the results? If your particular kind of system has already been done then there is no need to do so. J5.03a. timer=: 6!:2 timer 'x*x' [ x=: 1e7 $ _ timer 'x*x' [ x=: 1e7 ?@$ 0 no _ _ P3 0.882357 2.06805 P4 0.327353 5.66807 Celeron Linux MAC ? ======================================================================== Message-ID: <030f01c42df5$11c38440$60c15718@lap> Date: Thu, 29 Apr 2004 07:19:49 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM There already are _ and __ as extended precision integers and rationals: % 0 1r2 _ 2 ! _ 40x _ 815915283247897734345611269596115894272000000000 ----- Original Message ----- From: "Don Guinn" To: Sent: Thursday, April 29, 2004 7:06 AM Subject: Re: [Jforum] Optimization of */ Neville Holmes wrote: > >I've been teaching some student engineers programming, and, >frankly, many are not capable of understanding such matters. > I am surprised that engineers would have difficulty with this. They should be most capable of understanding. After all, they should already know that they are dealing with inaccurate measurements before they ever get to the computer. There are many fields of science and engineering where it is sometimes difficult to even have one significant digit of accuracy in measurements. However, a suggestion to Roger, how about adding two special rational values for _ and __? Just as it is nice to include _ or __ in real (floating point) arrays it would be nice to be able to include _ and __ in rational arrays without forcing a conversion to real. This would be especially true when numbers in the rational array exceed the largest real in hardware. I have no idea what the implications of this would be on the internals of J, but it would give a better parallel between rationals and reals. ======================================================================== Message-ID: <034101c42dfa$ed459210$60c15718@lap> Date: Thu, 29 Apr 2004 08:01:55 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM Yes, it's all as it should be. Comments appended: INF=.%0x type=.3!:0 type INF NB. x integers stay as x integers if possible 64 type INF,1r2 NB. x integer and rational coerce to rational 128 type _,1r2 NB. float and rational coerce to float 8 NB. _ by itself is float NB. this example is similar to 1.5,1r2 type INF,1 NB. x integer and boolean coerce to x integer 64 The relationships between the types are specified in section II G of the dictionary. The key table is: | B I X Q D Z ---+------------------ B | B I X Q D Z B - boolean I | I I X Q D Z I - integer X | X X X Q D Z X - extended integer Q | Q Q Q Q D Z Q - rational D | D D D D D Z D - floating point Z | Z Z Z Z Z Z Z - complex The mnemonic is that B I X Q D Z are ordered (B is less than I is less than X ...), and this table is the max table. ----- Original Message ----- From: "Don Guinn" To: Sent: Thursday, April 29, 2004 7:48 AM Subject: Re: [Jforum] Optimization of */ I guess where things get messy in this area is the way rationals are promoted to real. Maybe there are circumstances where the promotion should be the other way. INF=.%0x type=.3!:0 type INF 64 type INF,1r2 128 type _,1r2 8 type INF,1 64 ======================================================================== Message-ID: <039701c42e06$5fefd090$60c15718@lap> Date: Thu, 29 Apr 2004 09:23:35 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM Thanks to all readers who contributed results. The following is a summary. timer=: 6!:2 timer 'x*x' [ x=: 1e7 $ _ NB. all infinity timer 'x*x' [ x=: 1e7 ?@$ 0 NB. no infinity no inf all inf ratio Pentium 3 Win 0.882357 2.06805 2.34 Pentium 3 Win 0.902579 1.56029 1.73 Pentium 3 Linux 1.38671 3.85603 2.78 MAC G3 2.6209 2.54899 0.97 Pentium M 0.311368 1.81875 5.84 Pentium M 0.268108 1.76535 6.58 Pentium 4 0.327353 5.66807 17.31 Pentium 4 0.317 6.327 19.96 Pentium 4 Linux 0.243348 5.1978 21.36 Pentium 4 Linux 0.103546 6.31651 61 (?) (? The is from Patrick Harrington. I wonder if the timings are repeatable?) As I said, I think the performance of _ has deteriorated with the later Pentiums. And, ... You really can find everything on Googol these days. I entered "Pentium 4 infinity multiply speed" in Googol and selected the first hit. Fascinating reading. http://www.cygnus-software.com/papers/infinitytestresults.html ======================================================================== Message-ID: <03b401c42e08$b5d3a8e0$60c15718@lap> Date: Thu, 29 Apr 2004 09:40:34 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM There is an obvious future extension. The current types are: | B I X Q D Z ---+------------------ B | B I X Q D Z B - boolean I | I I X Q D Z I - integer X | X X X Q D Z X - extended integer Q | Q Q Q Q D Z Q - rational D | D D D D D Z D - floating point Z | Z Z Z Z Z Z Z - complex We could implement a couple of new types, extended precision floats and extend precision complex, collectively called "big floats". (Or perhaps just one new type, the complex one.) They (or it) can be slotted as follows: | B I X Q D Z DX ZX ---+------------------------- B | B I X Q D Z DX ZX B - boolean I | I I X Q D Z DX ZX I - integer X | X X X Q DX ZX DX ZX X - extended integer Q | Q Q Q Q DX ZX DX ZX Q - rational D | D D DX DX D Z DX ZX D - floating point Z | Z Z ZX ZX Z Z ZX ZX Z - complex DX | DX DX DX DX DX ZX DX ZX DX - extended precision float ZX | ZX ZX ZX ZX ZX ZX ZX ZX ZX - extended precision complex Thus if you are in the extended precision domains, you don't ever drop back into the small precision domains (unless you explicitly do so through the x: verb). There will still be a loss of precision from rationals to big floats (which would only have a finite number of digits), but the loss wouldn't be as bad. ----- Original Message ----- From: "Don Guinn" To: Sent: Thursday, April 29, 2004 9:17 AM Subject: Re: [Jforum] Optimization of */ I agree. I guess what's bothering me is that before extended integers and rationales appeared as you moved down the table the next type could exactly represent the one before. It is a proper superset. No loss of precision or maximum and minimum values. This was one of the pleasing aspects of the table. But extended integers and rationales mess up that pattern. Rationales can exactly represent any floating point number but the reverse is not true. Of course, rationales cannot represent complex, at least, not yet. ======================================================================== Message-ID: <044601c42e19$1119f370$60c15718@lap> Date: Thu, 29 Apr 2004 11:37:36 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM I missed the problem the first time, but the space numbers gave the jarring clue. The test is to compare floating point multiply on ordinary numbers against floating point multiply on infinity. The second expression x=: 1e7 $ 0 gives boolean 0s rather than floating point numbers. Please do: timer 'x*x' [ x=: 1e7 ?@$ 0 n ?@$ 0 is a phrase ("idiom") for generating n random numbers from U[0,1]. ----- Original Message ----- From: "J. Patrick Harrington" To: Sent: Thursday, April 29, 2004 11:10 AM Subject: Re: [Jforum] Optimization of */ timer 'x*x' [ x=: 1e7 $ _ 6.38297 timer 'x*x' [ x=: 1e7 $ 0 0.103097 timer 'x*x' [ x=: 1e7 $ _ 6.37046 timer 'x*x' [ x=: 1e7 $ 0 0.10336 timer 'x*x' [ x=: 1e7 $ 0 0.104221 5 ts 'x*x' [ x=: 1e7 $ 0 0.102856 1.67779e7 timer 'x*x' [ x=: 1e7 $ _ 5 ts 'x*x' [ x=: 1e7 $ _ 6.26725 1.34218e8 ======================================================================== Message-ID: <046801c42e20$472c4010$60c15718@lap> Date: Thu, 29 Apr 2004 12:29:19 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM > It seems like most of the platforms provide (except MAC G3) > provide significant improvement when infinities are not used. That is an odd way of putting it. The situation is that on the Pentium performance degrades when infinities (and other special numbers) are used. The Cygnus paper I linked to earlier noted that there is no performance degradation on the Athlon. Your numbers confirm that. ----- Original Message ----- From: "Mark D. Niemiec" To: Sent: Thursday, April 29, 2004 12:12 PM Subject: Re: [Jforum] Optimization of */ Roger Hui wrote: > timer=: 6!:2 > timer 'x*x' [ x=: 1e7 $ _ NB. all infinity > timer 'x*x' [ x=: 1e7 ?@$ 0 NB. no infinity It seems like most of the platforms provide (except MAC G3) provide significant improvement when infinities are not used. timer 'x*x' [ x=: 1e7 $ _ 0.27037 timer 'x*x' [ x=: 1e7 ?@$ 0 NB. Repeating this varies result by about 1-2% 0.30524 My own results got a ratio of around 0.9. I am using an Athlon XP 2600 running at 1.8 GHz. This is curious that both AMD and Apple CPUs treat infinities marginally faster than other numbers (as one might expect), while Intel CPUs deal with them much more slowly than others. (Perhaps they are treating them like 2^1024 and normalizing the other value by repatedly shifting it?) -- Mark D. Niemiec ======================================================================== Message-ID: <047f01c42e21$884d43e0$60c15718@lap> Date: Thu, 29 Apr 2004 12:38:08 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM It's documented in the J 5.03 release notes. I "borrowed" the idea of extending the domain of ?x to 0 from Arthur Whitney and k. Likewise the idea of having special code for x ?@$ y . ----- Original Message ----- From: "Randy MacDonald" To: Sent: Thursday, April 29, 2004 12:25 PM Subject: Re: [Jforum] Optimization of */ ----- Original Message ----- From: "Roger Hui" To: Sent: Thursday, April 29, 2004 2:37 PM Subject: Re: [Jforum] Optimization of */ ... > n ?@$ 0 is a phrase ("idiom") for generating n random > numbers from U[0,1]. Bravo. Don't forget to ducument this feature. That is actually not quite so straightforward in APL. It's one of those "why didn't we do this decades ago" features. ======================================================================== Message-ID: <048f01c42e22$485b1130$60c15718@lap> Date: Thu, 29 Apr 2004 12:42:39 -0700 Reply-To: J Forum From: Roger Hui Subject: Re: [Jforum] Optimization of */ To: JFORUM@PEACH.EASE.LSOFT.COM We had a utility in Sharp APL that did this; the process is called "distributed rounding". ----- Original Message ----- From: "Anthony Camacho" To: Sent: Thursday, April 29, 2004 12:34 PM Subject: Re: [Jforum] Optimization of */ Ralph Selfridge wrote: > And to add a different point of view, many years ago when 4 places was > all the system really gave, and input data rarely had that much accuracy, > but users wanted 8 place results, we just added 4 random digits to printed > output, did no damage to their analysis and kept everyone happy. In the 1950s when I worked for Nielsen, to make the sample areas add up to the universe we used a factor 'the lacing factor' to force the sum of the cells to equal the universe. ('Lacing' because it made things tie up!) The customers could not understand that samples were approximate! Anthony ========================================================================