Tài liệu Thuật toán Algorithms (Phần 22) pdf

HASHTNG 203 type link=fnode; node=record key, info: integer; next: link end; var heads: array [O M] of link; t, z: link; procedure initialize; var i: integer; begin new(z); zt.next:=z; for i:=O to M-l do begin new(heads[i]); heads[i]f.next:=z end; end ; Now the procedures from Chapter 14 can be used as is, with a hash function used to choose among the lists. For example, listinsert(v, heads[v mod M] ) can be used to add something to the table, t:=listsearch(v, heads[v mod M]) to find the first record with key v, and successively set t:=listsearch(v, t) until t=z to find subsequent records with key v. For example if the ith letter in the alphabet is represented with the number i and we use the hash function h(k) = kmod M, then we get the following hash values for our sample set of keys with M = 11: Key: ASEARCHINGEXAMPLE Hash: 18517389375212515 if these keys are successively inserted into an initially empty table, the follow- ing set of lists would result: 0 1 2 3 4 5 6 7 8 9 10 AMC E G H I A X N E R S A E L P Obviously, the amount of time required for a search depends on the length of the lists (and the relative positions of the keys in them). The lists could be left unordered: maintaining sorted lists is not as important for this application as it was for the elementary sequential search because the lists are quite short. For an “unsuccessful search” (for a record with a key not in the table) we can assume that the hash function scrambles things enough so that each of 204 CHAPTER 16 the M lists is equally likely to be searched and, as in sequential list searching, that the list searched is only traversed halfway (on t,he average). The average length of the list examined (not counting z) in this example for unsuccessful search is (0+4+2+2+0+4+0+2+2+1+0)/11 z 1.545. This would be the average time for an unsuccessful search were the lists unordered; by keeping them ordered we cut the time in half. For a “successful search” (for one of the records in the table), we assume that each record is equally likely to be sought: seven of the keys would be found as the first list item examined, six would be found as the second item examined, etc., so the average is (7.1+ 6.2 + 2.3 + 2.4)/17) z 1.941. (This count assumes that equal keys are distinguished with a unique identifier or some other mechanism, and the search routine modified appropriately to be able to search for each individual key.) If N, the number of keys in the table, is much larger than M then a good approximation to the average length of the lists is N/M. As in Chapter 14, unsuccessful and successful searches would be expected to go about halfway down some list. Thus, hashing provides an easy way to cut down the time required for sequential search by a factor of M, on the average. In a separate chaining implementation, M is typically chosen to be rela- tively small so as not to use up a large area of contiguous memory. But it’s probably best to choose M sufficiently large that the lists are short enough to make sequential search the most efficient method for them: “hybrid” methods (such as using binary trees instead of linked lists) are probably not worth the trouble. The implementation given above uses a hash table of links to headers of the lists containing the actual keys. Maintaining M list header nodes is somewhat wasteful of space; it is probably worthwhile to eliminate them and make heads be a table of links to the first keys in the lists. This leads to some complication in the algorithm. For example, adding a new record to the beginning of a list becomes a different operation than adding a new record anywhere else in a list, because it involves modifying an entry in the table of links, not a field of a record. An alternate implementation is to put the first key within the table. If space is at a premium, it is necessary to carefully analyze the tradeoff between wasting space for a table of links and wasting space for a key and a link for each empty list. If N is much bigger than M then the alternate method is probably better, though M is usually small enough that the extra convenience of using list header nodes is probably justified. Open Addressing If the number of elements to be put in the hash table can be estimated in advance, then it is probably not worthwhile to use any links at all in the hash table. Several methods have been devised which store N records in a table HASHING 205 of size A4 > N, relying on empty places in the table to help with collision resolution. Such methods are called open-addressing hashing methods. The simplest open-addressing method is called linear probing: when there is a collision (when we hash to a place in the table which is already occupied and whose key is not the same as the search key), then just probe the next position in the table: that is, compare the key in the record there against the search key. There are three possible outcomes of the probe: if the keys match, then the search terminates successfully; if there’s no record there, then the search terminates unsuccessfully; otherwise probe the next position, continuing until either the search key or an empty table position is found. If a record containing the search key is to be inserted following an unsuccessful search, then it can simply be put into the empty table space which terminated the search. This method is easily implemented as follows: type node=record key, info: integer end; var a: array [O M] of node; function h(k: integer): integer; begin h:=k mod Mend; procedure hashinitialize; var i: integer; begin for i:=O to M do a[i].key:=maxint; end ; function hashinsert (v: integer) : integer; var x: integer; begin x:=h(v); while a[x].key<>maxint do x:=(x+1) mod M; a [x] .key:=v; hashinsert :=x; end ; Linear probing requires a special key value to signal an empty spot in the table: this program uses maxint for that purpose. The computation x:=(x+1) mod M corresponds to examining the next position (wrapping back to the beginning when the end of the table is reached). Note that this program does not check for the table being filled to capacity. (What would happen in this case?) The implementation of hashsearch is similar to hashinsert: simply add the condition “a [x] .key< >v” to the while loop, and delete the following instruction which stores v. This leaves the calling routine with the task 206 CHAPTER 16 of checking if the search was unsuccessful, by testing whether the table position returned actually contains v (successful) or maxi& (unsuccessful). Other conventions could be used, for example hashsearch could return M for unsuccessful search. For reasons that will become obvious below, open addressing is not appropriate if large numbers of records with duplicate keys are to be processed, but hashsearch can easily be adapted to handle equal keys in the case where each record has a unique identifier. For our example set of keys with A4 = 19, we might get the hash values: Key: ASEARCHINGEXAMPLE Hash: 1 0 5 1 18 3 8 9 14 7 5 5 1 13 16 12 5 The following table shows the steps of successively inserting these into an initially empty hash table: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 - SAA E SAAm E SAAC E 0 H SAAC E HIII SAAC E H I 0 N SAAC E 0 GHI N SAAC R~~GHI SAAC ~~~~~~ : SmbimwEEGHIX N SAACAEEGHIX 0 MN SAACAEEGHIX MN SAACAEEGHIX L-l LMN SAACA~~~~~~lE]LMN 0 R R R R R R R R R R 0 P R P R P R HASHING 207 The table size is greater than before, since we must have M > N, but the total amount of memory space used is less, since no links are used. The average number of items that must be examined for a successful search for this example is: 33/17 z 1.941. Linear probing (indeed, any hashing method) works because it guarantees that, when searching for a particular key, we look at every key that hashes to the same table address (in particular, the key itself if it’s in the table). Unfortunately, in linear probing, other keys are also examined, especially when the table begins to fill up: in the example above, the search for X involved looking at G, H, and I which did not have the same hash value. What’s worse, insertion of a key with one hash value can drastically increase the search times for keys with other hash values: in the example, an insertion at position 17 would cause greatly increased search times for position 16. This phenomenon, called clustering, can make linear probing run very slowly for nearly full tables. Fortunately, there is an easy way to virtually eliminate the clustering problem: double hashing. The basic strategy is the same; the only difference is that, instead of examining each successive entry following a collided position, we use a second hash function to get a fixed increment to use for the “probe” sequence. This is easily implemented by inserting u:=h2(v) at the beginning of the procedure and changing x:=(x+1) mod M to x:=(x+u) mod M within the while loop. The second hash function h2 must be chosen with some care, otherwise the program might not work at all. First, we obviously don’t want to have u=O, since that would lead to an infinite loop on collision. Second, it is important that M and u be relatively prime here, since otherwise some of the probe sequences could be very short (for example, consider the case M=2u). This is easily enforced by making M prime and u<M. Third, the second hash function should be “different” from the first, otherwise a slightly more complicated clustering could occur. A function such as hz(k) = M - 2 - k mod (M - 2) will produce a good range of “second” hash values. For our sample keys, we get the following hash values: Key ASEARCHINGEXAMPLE Hash 1: 1 0 5 1 18 3 8 9 14 7 5 5 1 13 16 12 5 Hash 2’: 16 15 12 16 16 14 9 8 3 10 12 10 16 4 1 5 12 The following table is produced by successively inserting our sample keys into an initially empty table using double hashing with these values. 208 CHAPTER 16 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 0 A 0 S A S A aI S A S A S A S A S A S A S A S A sm S A S A S A sB 0 C C C C C C C C C C C 0 C lEl E 0 A E Al-4 E AR E IHI AR E Hl2-l AR E H I 0 N AR - E IGI H I N AR 0 E TH Im N 0 AR 0 E GHIE NM AR E GHIEm 0 NX AR cl E GHIEA r-l MNX AR E GHIEA MNX~AR - E GHIEAMMNXPAR ~~G~I~AL~N~PMR This technique uses the same amount of space as linear probing but the average number of items examined for successful search is slightly smaller: 32/17 z 1.882. Still, such a full table is to be avoided as shown by the 9 probes used to insert the last E in this example. Open addressing methods can be inconvenient in a dynamic situation, when an unpredictable number of insertions and deletions might have to be processed. First, how big should the table be? Some estimate must be made of how many insertions are expected but performance degrades drastically as the table starts to get full. A common solution to this problem is to rehash everything into a larger table on a (very) infrequent basis. Second, a word of caution is necessary about deletion: a record can’t simply be removed from a table built with linear probing or double hashing. The reason is that later insertions into the table might have skipped over that record, and searches for those records will terminate at the hole left by the deleted record. A way to solve this problem is to have another special key which can serve as a placeholder for searches but can be identified and remembered as an HASHING 209 empty position for insertions. Note that neither table size nor deletion are a particular problem with separate chaining. Analytic Results The methods discussed above have been analyzed completely and it is pos- sible to compare their performance in some detail. The following formulas, summarized from detailed analyses described by D. E. Knuth in his book on sorting and searching, give the average number of items examined (probes) for unsuccessful and successful searching using the methods we’ve studied. The formulas are most conveniently expressed in terms of the “load factor” of the hash table, cr = N/M. Note that for separate chaining we can have CY > 1, but for the other methods we must have Q < 1. Unsuccessful Successful Separate Chaining: 1+ 42 (a + 1)/Z Linear Probing: l/2+1/2(1-42 1/2+1/2(1-a) Double Hashing: l/(1 - a) - ln( 1 - o)/o For small o, it turns out that all the formulas reduce to the basic result that unsuccessful search takes about 1 + N/M probes and successful search takes about 1 + N/2M probes. (Except, as we’ve noted, the cost of an unsuccessful search for separate chaining is reduced by about half by ordering the lists.) The formulas indicate how badly performance degrades for open addressing as CY gets close to 1. For large M and N, with a table about 90% full, linear probing will take about 50 probes for an unsuccessful search, compared to 10 for double hashing. Comparing linear probing and double hashing against separate chaining is more complicated, because there is more memory available in the open addressing methods (since there are no links). The value of CY used should be modified to take this into account, based on the relative size of keys and links. This means that it is not normally justified to choose separate chaining over double hashing on the basis of performance. The choice of the very best hashing method for a particular applica- tion can be very difficult. However, the very best method is rarely needed for a given situation, and the various methods do have similar performance characteristics as long as the memory resource is not being severely strained. Generally, the best course of action is to use the simple separate chaining method to reduce search times drastically when the number of records to be processed is not known in advance (and a good storage allocator is available) and to use double hashing to search among a set of keys whose size can be roughly predicted ahead of time. Many other hashing methods have been developed which have application in some special situations. Although we can’t go into details, we’ll briefly 210 CHAPTER 16 consider two examples to illustrate the nature of specially adapted hashing methods. These and many other methods are fully described in Knuth’s book. The first, called ordered hashing, is a method for making use of ordering within an open addressing table: in standard linear probing, we stop the search when we find an empty table position or a record with a key equal to the search key; in ordered hashing, we stop the search when we find a record with a key greater than or equal to the search key (the table must be cleverly constructed to make this work). This method turns out to reduce the time for unsuccessful search to approximately that for successful search. (This is the same kind of improvement that comes in separate chaining.) This method is useful for applications where unsuccessful searching is frequently used. For example, a text processing system might have an algorithm for hyphenating words that works well for most words, but not for bizarre cases (such as “bizarre”). The situation could be handled by looking up all words in a relatively small exception dictionary of words which must be handled in a special way, with most searches likely to be unsuccessful. Similarly, there are methods for moving some records around during unsuccessful search to make successful searching more efficient. In fact, R. P. Brent developed a method for which the average time for a successful search can be bounded by a constant, giving a very useful method for applications with frequent successful searching in very large tables such as dictionaries. These are only two examples of a large number of algorithmic improve- ments which have been suggested for hashing. Many of these improvements are interesting and have important applications. However, our usual cautions must be raised against premature use of advanced methods except by experts with serious searching applications, because separate chaining and double hashing are simple, efficient, and quite acceptable for most applications. Hashing is preferred to the binary tree structures of the previous two chapters for many applications because it is somewhat simpler and it can provide very fast (constant) searching times, if space is available for a large enough table. Binary tree structures have the advantages that they are dynamic (no advance information on the number of insertions is needed), they can provide guaranteed worst-case performance (everything could hash to the same place even in the best hashing method), and they support a wider range of operations (most important, the sort function). When these factors are not important, hashing is certainly the searching method of choice. 0 HASHING 211 Exercises 1. Describe how you might implement a hash function by making use of a good random number generator. Would it make sense to implement a random number generator by making use of a hash function? 2. How long could it take in the worst case to insert N keys into an initially empty table, using separate chaining with unordered lists? Answer the same question for sorted lists. 3. Give the contents of the hash table that results when the keys E A S Y Q U E S T I 0 N are inserted in that order into an initially empty table of size 13 using linear probing. (Use hi(k) = kmod 13 for the hash function for the lath letter of the alphabet.) 4. Give the contents of the hash table that results when the keys E A S Y Q U E S T I 0 N are inserted in that order into an initially empty table of size 13 using double hashing. (Use hi(k) from the previous question, hz(lc) = 1 + (Ic mod 11) for the second hash function.) 5. About how many probes are involved when double hashing is used to build a table consisting of N equal keys? 6. Which hashing method would you use for an application in which many equal keys are likely to be present? 7. Suppose that the number of items to be put into a hash table is known in advance. Under what condition will separate chaining be preferable to double hashing? 8. Suppose a programmer has a bug in his double hashing code so that one of the hash functions always returns the same value (not 0). Describe what happens in each situation (when the first one is wrong and when the second one is wrong). 9. What hash function should be used if it is known in advance that the key values fall into a relatively small range? 10. Criticize the following algorithm for deletion from a hash table built with linear probing. Scan right from the element to be deleted (wrapping as necessary) to find an empty position, then scan left to find an element with the same hash value. Then replace the element to be deleted with that element, leaving its table position empty.