| Re: Is there a better way? [message #9162] |
Wed, 11 June 1997 00:00 |
Stein Vidar Hagfors H
Messages: 32
Registered: May 1997
|
Member |
|
|
Kelly Dean wrote:
>
> Is there a better way to locate a value in a table (or array)? I would
> like to come in with an array of radaince values and convert them to
> temperatures. The method below only takes the one number (rad) then
> search for the best match in the table (or array).
>
> If you can thing of a better method, send me a note.
Well, I can suggest a couple of things that will probably
speed up the routine considerably, though I can't guarantee
that it's the *best* way...
> =================================================
> FUNCTION IS_THERE_A_BETTER_WAY, rad
>
If the table you're using is actually created this way,
I'd use a common block as a cache to avoid initializing
the tables on each call, e.g.:
COMMON IS_THERE_A_BETTER_WAY_CACHE,WVTEMParr,WVRADarr
IF n_elements(WVTEMParr) eq 0 THEN BEGIN
<initialize arrays here>
ENDIF
Instead of looping etc, I'd put my money on IDL's array processing
capabilities:
absdiff = abs(WVRADarr - rad)
dummy = min(absdiff,minix) ; Minix now contains the index of
; the point with the minimum abs diff.
return,WVTEMParr(minix)
> END
Unless your real arrays are very large, this is probably
faster than a search in a sorted array, due to the slow
execution of single statements vs array operations.
A native IDL routine doing a sorted search should be
available, though.... haven't found one yet....
Stein Vidar
|
|
|
|
| Re: Is there a better way? [message #9169 is a reply to message #9162] |
Tue, 10 June 1997 00:00  |
William Clodius
Messages: 30
Registered: December 1996
|
Member |
|
|
Kelly Dean wrote:
>
> Is there a better way to locate a value in a table (or array)? I would
> like to come in with an array of radaince values and convert them to
> temperatures. The method below only takes the one number (rad) then
> search for the best match in the table (or array).
>
> If you can thing of a better method, send me a note.
The best routine depends on the detailed statistics of your data, i.e.
it is often appropriate to cache the last point and search outwards.
The following takes of the order log base 2 of 200 operations, i.e., 8 *
a small factor, while your method takes on the order of 200 operations,
unless the data always lies at small values.
lbound= 0
ubound = 199
guess = 100
while ubound - lbound gt 1 do begin
IF rad GT WVRADarr(guess) then $
lbound = guess $
else ubound = guess
guess = (ubound + lbound) / 2L
endwhile
TempK = WVTEMParr(lbound)
The following should be a vectorizable version of the same idea
lbound = Lonarr(N_elements(rad))
ubound = lbound + 199
guess = lbound + 100
n_iterate = 9
for i=0, n_iterate-1 do begin
ndx = where(rad GT WVRADarr(guess), count)
if count gt 0 then lbound(ndx) = guess(ndx)
ndx = where(rad LE WVRADarr(guess), count)
if count gt 0 then ubound(ndx) = guess(ndx)
guess = (ubound + lbound) / 2L
endfor
TempK = WVTEMParr(lbound)
Mind you I haven't checked the following for boundary conditions, in
particular it might be that n_iterate should be 8 or lbound might be off
by 1 from what you want.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclodius@lanl.gov
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
