Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Argument starter - The roots of all evil
Message
De
09/09/2004 08:34:00
 
 
À
09/09/2004 05:10:57
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00938079
Message ID:
00940558
Vues:
46
>I'm so sorry :-C. I guess I did commit that message b4 reading your argument (it was yours, wasn't it?) that the time differences don't add up to a hill of beans. And then I said only if a huge list that would take seconds rather than fractions thereof. I'm, of course, interested in what you just said. What exactly do you mean by "binary search"? As I learnt it in college it means going backward and foreward in the list, halving the distance as you go (in essence). If that's so, please could you indicate how does ascan() do it, and how you would do it via a do while?
>

The first FoxPro (actually, FoxBase) article I ever published was about sorting and searching in arrays. This was before we had the ASORT() and ASCAN() functions.

Binary search is an extremely fast searching technique that's useful when the list to be searched is ordered. When you search sequentially, on average, you'll have to touch half the items in the list.

With binary search, you start by looking at the item in the middle. If it's the one you want, you're done. If it's larger than the one you want, look only to the left (assuming ascending sort); if it's smaller, look only to the right. Take the remaining list and look in the middle, repeating the process as needed. It turns out that using this approach, on average, you look at log2(n) (that is, the logarithm of n to the base 2).

For a list of 64 items, sequential search averages to 32, while binary averages 6. The bigger the list, the greater the advantage of binary search.

Also worth noting that what we do when faced with actual physical searches of sorted info (like a dictionary or phone book) is similar to binary search.

As for ASCAN(), I'm not sure what algorithm is uses, given that it doesn't necessarily have sorted data. However, we've certainly learned over the years that when the VFP team gives us something in C code, it'll almost always run faster than the equivalent VFP code we could write. (Actually, that's an interesting test. Take a large array, populate it randomly, and then use ASCAN() and brute force code to search for random items.)

Tamar
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform