[Numpy-discussion] optimization of arr**-2

[Timothy Hochberg]

On 7/15/07, Sebastian Haase <haase@msg.ucsf.edu> wrote:
>
> Hi,
> I compared for a 256x256 float32  normal-noise (x0=100,sigma=1) array
> the times to do
> 1./ (a*a)
> vs.
> a**-2
>
> >>> U.timeIt('1./(a*a)', 1000)
> (0.00090877471871, 0.00939644563778, 0.00120674694689, 0.000687777554628)
> >>> U.timeIt('a**-2', 1000)
> (0.00876591857354, 0.0263829620803, 0.00952076311375, 0.00173311803255)
>
> The numbers are min,max, mean, stddev over thousand runs.
> N.__version == 1.0.1
>
> The slowdown is almost 10 fold.  Similar tests for **-1, and **2  show
> that the corresponding times are identical - i.e. those cases are
> optimized to not call the pow routine.
>
> Can this be fixed for the **-2 case ?


Not without some testing and discussion. If I recall correctly, we fixed all
of the cases where the optimized case had the same accuracy as the
unoptimized case. Optimizing 'x**-2', because it involves two operations (*
and /), starts to become lose accuracy relative to pow(x,-2). The accuracy
loss is relatively minor however; an additional ULP (unit in last place) or
so, I believe. It's been a while however, so I may have the details
scrambled.

So, while I'm not dead set against it, I think we would definitely come to a
consensus on how much accuracy we are willing to forgo for these notational
conveniences. And document accordingly. The uncontroversial ones already got
optimized.

Then again, we could just leave things as they are and when you're hungry
for speed, you could use '1/x**2'.


-- 
.  __
.   |-\
.
.  tim.hochberg@ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20070715/2d6f5950/attachment.html