MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: an even faster way to normalize a


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


  • Prev by Date: Re: an even faster way to normalize a
  • Next by Date: Multiple data sets with ListPlot and different PointSizes - Mesh
  • Previous by thread: Re: an even faster way to normalize a
  • Next by thread: Re: an even faster way to normalize a