#Help
Hello Jim,
Ok, I've got to ask. Are you _the_ Jim Butterfield of the C64 days?
If so I have to thank you for all your help back when I didn't know a peek from
a poke. Because of people like you, understanding these wonderful little
machines became a lot easier.
> The traditional way to find an item in an ordered list is by a binary split
>search. In other words, you go to the middle of the list, and depending on
>whether your search value is higher or lower, move up or down 1/4 of the
length >of the list .. then 1/8, and so on.
Yes, I am familiar with this. I am opting to try something different, something
new. With each new program I try to improve my technique, and not rely on the
same old methods.
> If your material is purely alphabetic, that is, you can depend on the first
>character being A through Z, you can save time over the above method by
>building a list: where A starts, where B starts, etc. You don't have to
>search THIS index list; just go straight to the letter you want to find a
>starting point for your search.
I have been rolling this idea around, but I'm not sure it will be faster than
the binary split method. Deciding where to start looking will be quick, but
from there I still must locate the word in question.
> A variation on the above is the "linked list"; all the As are linked
>together, then all the Bs, and so on. Nice thing about links is that you can
>set them up to search on more than one key value.
This I haven't done before, I'll have to see what information I can dig up on
this.
> You'll undoubtedly get a number of suggestions about putting your data into
>a "tree" structure, where each above/below test points you to the next set of
>tests to do. There are many variations on this one.
I've heard of this type, and I'm trying to find some examples on this. Would
this not be similar to the binary split method, only reshaped into a tree?
I like the idea of having only two test to perform as with the binary split
(simplicity is best), would the same be possible with a tree method?
> If your objective is to find "hits" in the table – you don't care about
>values that will not turn out to find a match – you can go to a "hashing"
>technique. This is a little wasteful of memory, but it's real fast: by
>crunching together the alphabetic characters in mathematical fashion, you can
>generate an index number that will take you straight to the match, if it
>exists.
This sounds interesting, do you know of anyplace on-line I might look to find
an example or an in-depth description?
> Searching (and its cousin, sorting) is a major area of computer science
>study. Most of us cobble together something that works nicely for the
>application we have on hand.
As I'm beginning to see 🙂
Thanks for all your input regarding my question Jim. Programing is somewhat of
a passion of mine, and these types of hints from the experts helps a lot.
I'm currently taking a course in C and VB in the hopes of someday being able to
make a living programing. As of now I try to keep active by helping out where
I can, mostly with the ACE basic compiler by David Benn. I do the amigaguide
docs for him and try to answer a few questions for other users of ACE.
It's been a pleasure talking to you, brought back a lot of old memories 🙂
Best Regards -John