Re: an even faster way to normalize a

*To*: mathgroup at smc.vnet.net*Subject*: [mg85663] Re: an even faster way to normalize a*From*: congruentialuminaire at yahoo.com*Date*: Tue, 19 Feb 2008 01:47:15 -0500 (EST)*References*: <fp9945$199$1@smc.vnet.net>

Hello UG: Thanks [as always] for your very helpful replies. The results are interesting... The bigger issue with this code I am trying to optimize is *precision*. This dawned on me when I read the replies that came through, since they contained approximate numbers in the 3-tuples. I just started on those "nested For's", since I view them as "ugly", to quote one respondent. Here is a summary of some tests I ran: All tests were run on 3 cases: exact numbers (i.e. fractions), machine precision and 20-digit precision (250,000 3-tuples). To get true timing numbers, the tests should be run dozens of times (at least). I did not do this. 'For loops' on exact numbers are faster than 'For loops' on approximate numbers (both types). Map solutions on exact numbers are 25% faster than 'For loops' on exact numbers. Map solutions on approximate numbers are 6 times faster than 'For loops' on approximate numbers. Map solutions on approximate numbers are 4 times faster than Map solutions on exact numbers. I am also using Show[Graphics[Raster[.... and I think Trott shows that Graphics[] "likes" approximate numbers, so.. The final routine displays about 35% faster using 20-digit precision and just as fast but "incorrect output" using machine-precision. The outputs from the tests are: exact machPrec 20digPrec For's 1.03 1.54 1.54 Map .797 .234 .266 I was surprised that this small test case had such good illustrations of functional/procedural programming and precision issues. Regards..Roger W. On Feb 17, 4:25=A0am, congruentialumina... at yahoo.com wrote: > Hello UG: > > <snipped/>