# Re: Was: Index... Now: Vectorize, huh?

```"Pavel A. Romashkin" <pavel.romashkin@noaa.gov> writes:

> Craig and Med,
>
> I appreciate it! This is exactly what I needed. My problem is the lack
> of matrix operations knowledge. Craig's generic solution is exactly what
> I expected to see from Craig :-)
>
> By the way. We all are big on vectorizing things in IDL. But look at this:
>
> IDL> a = test(2000)
>        1.4968959
> IDL> a = test(2000, /v)
>        3.2976190
>
> where TEST is below. I don't even mention that /VEC causes extremely
> high memory usage and gets totally out of hand on my system if S > 5000
> or so.
>
> ;******************************
> pro test, s, vec=vec
> start = systime(1)
> x = findgen(s)
> a = fltarr(s, s)
> if keyword_set(vec) then begin
> a = sqrt(transpose(rebin(x, s, s))^2 + rebin(x, s, s)^2)

Now, this is a bit unfair! First (but least), you're generating a useless "a =
fltarr.." for the vector case. Then, you're doing everything in the wrong
order (exploding the array first, then squaring it), and you're also using
a transpose when it is not necessary:

x2 = x^2 ; This could be used to speed up your "nonvectorized" code as well
a = sqrt(rebin(reform(x2,1,s,/overwrite), s, s) + \$
rebin(reform(x2,s,1,/overwrite), s, s))

(But still, non-vectorizing code is 2x faster (with the x2 = x^2
optimization): Running through the large arrays several times is the killer, I
suspect. It may be architecture dependant, I presume).

But then, your "nonvectorized" code *is* vectorized (x is a vector), and it's
generally accepted that avoiding loops don't really buy you much when
operating on very large units. It's an intriguing example, though!

And for e.g. s = 200 the vectorized code is slightly faster..

> endif else begin
> for i = 0, s-1 do begin
> a[0, i] = sqrt(x^2 + i^2.)
> endfor
> endelse
> print, systime(1) - start
> ;return, a
> end
> ;******************************

--
Stein Vidar Hagfors Haugan
ESA SOHO SOC/European Space Agency Science Operations Coordinator for SOHO
```