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