Re: "extract" command enhancement (subfiles and BIFs)

Incidentally, this "halving" technique is one I learned years ago in school 
from a
math teacher.  By using the halving technique, you can pick any number from 1
to 100 within 7 "guesses", with the average being 4 or 5 (not 3.5 because of the
refinement on each consecutive pick)..  On a simple sequential search, 1, 2, 3,
4, etc... it could take 100 picks, with the average being 50.  With 1000 records
the halving technique would take at most 10 guess, and I'm not even going to
try to figure out the average (7 maybe?).  With sequential search, max 1000 and
average of 500.

It's a really good technique, and I have used it in searches before, but there 
is
the necessity that your data is sorted on what you're looking for.  And this is
basically the exact same way the OS does it when it does a SETLL.

Regards,

Jim Langston

Incidentally, what does HTH mean?



"James W. Kilgore" wrote:

> Dan,
>
> Yes we load the whole subfile (but not necessarily the whole data base).  
>Years ago
> we did page at a time to give the false illusion of response time.  We also
> monitored what was going on and found out that -most- subfile usage displayed 
>500 or
> fewer records.
>
> With all the inherent problems of page at a time mentioned on this thread, we 
>opted
> to change our standard template.  Sure we still get a user that insists on 
>doing a
> customer search by just typing a single letter and they sit and wait and max 
>out the
> subfile.  When that occurs we send a status message telling them to refine 
>their
> search.  (we also capped the search to 2000 entries)
>
> It's the filtering of the data base that consumes the time, so that's where 
>our
> efforts are placed.  So in the customer search example, we started out using 
>an
> OPNQRYF as a filter mechanism, now we have a keyword in context file that we 
>can do
> a SETLL/READ on instead and that helped a whole lot more then page at a time 
>ever
> could.
>
> IMHO, it would be great if subfiles could be keyed (like data queues) and one 
>could
> use the SETLL/READ on them to set the page to be displayed.  But I'm not 
>holding my
> breath <g>
>
> For those that have not used binary halving, here's a little primer.
> Let's say you have a subfile (or ordered array) with 600 entries and you want 
>to
> "position to"
>
> To start the process, you get the key value at records 1 and 600 so you can 
>test if
> the request is within the range of entries.
> If it's not, you deal with it and bypass the whole halving process.
>
> You take the high number (600) and the low number (1) and find the midpoint 
>(300)
> You get the value at 300 and compare to your search argument.
>
> At this point you know that the result is in either the first or last half of 
>the
> subfile/array.  If you happen to hit it right on, set the subfile record 
>number or
> array index and leave the loop.
> (For this example let's say it's in the upper half)
>
> Now that you have made that determination, you go back to the top of the loop 
>and
> use 300 as your low number, 600 as the high number and find the midpoint (450)
> You get the value at 450 and compare to your search argument.
>
> Each iteration of the loop "halves" the remaining possibilities.  In the 
>example I
> posted, we stop the process once the spread between low/high numbers is 
>reduced to
> the subfile page size (usually 10) and start a simple looping chain/compare.
>
> HTH
>
> Dan Bale wrote:

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---