Re: I'd be interested in a discussion on the topic of LOOKUP vs.%LOOKUP

["Buck Calabro" <buck.calabro@xxxxxxxxxxxx>]

> LOOKUP is a linear search therefore
> the elapsed time is a function of
> the array size and on average will
> take N/2 lookups to find the search
> value.

In addition to Simon's comments, think about the 'not found'
condition.  If the search argument is not found in the table, LOOKUP
will test each element in the table, so the search will be quite a bit
longer than the average.  To be painfully clear, imagine a table with
2 elements:

BOOTH
BUCK

The code is designed to allow everyone access to the system except for
those in the table.  It's easy to do a LOOKUP, and if found, issue a
'not authorised' message and exit.  If the user is BUCK, the search
will take 2 comparisons.  If the user is BOOTH, the search will take
only one comparison.  If the user is SIMON, the search will take 2
comparisons.

Now, let's change the number of entries in the table to 1000, for
'future expansion.'  This is a fairly typical case, where a programmer
will try to think of the largest number of elements required now and
in the future.  Keep the same number of users in the table: 2.  Leave
the other 998 elements blank.  Looking up BUCK and BOOTH take the same
amount of comparisons as before, but now searching for SIMON will take
1000 comparisons.

Searching for a non-existent element with LOOKUP can be quite
expensive; possibly longer than doing a CHAIN.  This is one of those
cases I tend to cite when someone posts a performance question, and
the answer seems to be 'put it in an array.'  You need to benchmark it
with your own dataset on your own machine.
  --buck