Binary search algorithm - Wikipedia, the free encyclopedia

Transcription

1 1 of 12 9/8/2010 6:37 PM Binary search algorithm From Wikipedia, the free encyclopedia In computer science, a binary search is an algorithm for locating the position of an item in a sorted array. [1][2] The idea is simple: compare the target to the middle item in the list. If the target is the same as the middle item, you've found the target. If it's before the middle item, repeat this procedure on the items before the middle. If it's after the middle item, repeat on the items after the middle. The method halves the number of items to check each time, so it finds it or determines it's not present in logarithmic time. A binary search is a dichotomic divide and conquer search algorithm. Binary search algorithm Class Search algorithm Data structure Array Worst case performance O(log n) Best case performance O(1) Average case performance O(log n) Worst case space complexity O(1) Contents 1 Overview 2 Examples 2.1 Number guessing game 2.2 Word lists 2.3 Applications to complexity theory 3 The method 3.1 That it works 3.2 That it is fast Average performance Inserting and deleting elements 3.3 Extensions 3.4 Variations Exclusive or inclusive bounds Deferred detection of equality Midpoint and width 4 Computer usage 4.1 The algorithm Numerical difficulties Syntax difficulties 5 See also 4.2 Implementations Iterative Three-way comparison Recursive Single comparison per iteration 4.3 Language support

2 2 of 12 9/8/2010 6:37 PM 6 References 7 External links Overview It is useful to find where an item is in a sorted array. For example, if you had an array for contact information, with people's names, addresses, and telephone numbers sorted by name, you could use binary search to find out a few useful facts: whether the person's information is in the array, what the person's address is, and what the person's telephone number is. Binary search will take far fewer comparisons than a linear search, but there are some downsides. Binary search can be slower than using a hash table. If items are changed, the array will have to be re-sorted so that binary search will work properly, which can take so much time that the savings from using binary search aren't worth it. If you can tell ahead of time that a few items are disproportionately likely to be sought, putting those items first and using a linear search could be much faster.. Examples Number guessing game This rather simple game begins something like "I'm thinking of an integer between forty and sixty inclusive, and to your guesses I'll respond 'High', 'Low', or 'Yes!' as might be the case." Supposing that N is the number of possible values (here, twenty-one as "inclusive" was stated), then at most questions are required to determine the number, since each question halves the search space. Note that one less question (iteration) is required than for the general algorithm, since the number is already constrained to be within a particular range. Even if the number we're guessing can be arbitrarily large, in which case there is no upper bound N, we can still find the number in at most steps (where k is the (unknown) selected number) by first finding an upper bound by repeated doubling. [citation needed] For example, if the number were 11, we could use the following sequence of guesses to find it: 1, 2, 4, 8, 16, 12, 10, 11 One could also extend the technique to include negative numbers; for example the following guesses could be used to find 13: 0, 1, 2, 4, 8, 16, 12, 14, 13. Word lists People typically use a mixture of the binary search and interpolative search algorithms when searching a telephone book, after the initial guess we exploit the fact that the entries are sorted and can rapidly find the required entry. For example when searching for Smith, if Rogers and Thomas have been found, one can flip to a page about halfway between the previous guesses. If this shows Samson, we know that Smith is somewhere between the Samson and Thomas pages so we can bisect these. Applications to complexity theory Even if we do not know a fixed range the number k falls in, we can still determine its value by asking simple yes/no questions of the form "Is k greater than x?" for some number x. As a simple consequence of this, if you can answer the question "Is this integer property k greater than a given value?" in

3 3 of 12 9/8/2010 6:37 PM some amount of time then you can find the value of that property in the same amount of time with an added factor of log 2 k. This is called a reduction, and it is because of this kind of reduction that most complexity theorists concentrate on decision problems, algorithms that produce a simple yes/no answer. For example, suppose we could answer "Does this n x n matrix have determinant larger than k?" in O(n 2 ) time. Then, by using binary search, we could find the (ceiling of the) determinant itself in O(n 2 log d) time, where d is the determinant; notice that d is not the size of the input, but the size of the output. The method In order to discuss the method in detail, a more formal description is necessary. The basic idea is that there is a data structure represented by array A in which individual elements are identified as A(1), A(2),,A(N) and may be accessed in any order. The data structure contains a sub-element or data field called here Key, and the array is ordered so that the successive values A(1).Key A(2).Key and so on. The requirement is that given some value x, find an index p (not necessarily the one and only) such that A(p).Key = x. To begin with, the span to be searched is the full supplied list of elements, as marked by variables L and R, and their values are changed with each iteration of the search process, as depicted by the flowchart. Note that the division by two is integer division, with any remainder lost, so that 3/2 comes out as 1, not 1½. The search finishes either because the value has been found, or else, the specified value is not in the list. That it works The method relies on and upholds the notion If x is to be found, it will be amongst elements (L + 1) to (R 1) of the array.

4 4 of 12 9/8/2010 6:37 PM The initialisation of L and R to 0 and N + 1 make this merely a restatement of the supplied problem, that elements 1 to N are to be searched, so the notion is established to begin with. The first step of each iteration is to check that there is something to search, which is to say whether there are any elements in the search span (L + 1) to (R 1). The number of such elements is (R L 1) so computing (R L) gives (number of elements + 1); halving that number (with integer division) means that if there was one element (or more) then p = 1 (or more), but if none p = 0, and in that case the method terminates with the report "Not found". Otherwise, for p > 0, the search continues with p:=l + p, which by construction is within the bounds (L + 1) to (R 1). That this position is at or adjacent to the middle of the span is not important here, merely that it is a valid choice. Now compare x to A(p).Key. If x = A(p).Key then the method terminates in success. Otherwise, suppose x < A(p).Key. If so, then because the array is in sorted order, x will also be less than all later elements of the array, all the way to element (R 1) as well. Accordingly, the value of the right-hand bound index R can be changed to be the value p, since, by the test just made, x < A(p).Key and so, if x is to be found, it will be amongst elements earlier than p, that is (p 1) and earlier. And contrariwise, for the case x > A(p).Key, the value of L would be changed. Thus, whichever bound is changed the ruling notion is upheld, and further, the span remaining to be searched is reduced. If L is changed, it is changed to a higher number (at least L + 1), whereas if R is changed, it is to a lower number (at most R 1) because those are the limits for p. Should there have been just one value remaining in the search span (so that L + 1 = p = R 1), and x did not match, then depending on the sign of the comparison either L or R will receive the value of p and at the start of the next iteration the span will be found to be empty. Accordingly, with each iteration, if the search span is empty the result is "Not found", otherwise either x is found at the probe point p or the search span is reduced for the next iteration. Thus the method works, and so can be called an Algorithm. That it is fast With each iteration that fails to find a match at the probed position, the search is continued with one or other of the two sub-intervals, each at most half the size. More precisely, if the number of items, N, is odd then both sub-intervals will contain (N - 1)/2 elements. If N is even then the two sub-intervals contain N/2-1 and N/2 elements. If the original number of items is N then after the first iteration there will be at most N/2 items remaining, then at most N/4 items, at most N/8 items, and so on. In the worst case, when the value is not in the list, the algorithm must continue iterating until the span has been made empty; this will have taken at most log 2 (N) + 1 iterations, where the notation denotes the floor function that rounds its argument down to an integer. This worst case analysis is tight: for any N there exists a query that takes exactly log 2 (N) + 1 iterations. When compared to linear search, whose worst-case behaviour is N iterations, we see that binary search is substantially faster as N grows large. For example, to search a list of 1 million items takes as much as 1 million iterations with linear search, but never more than 20 iterations with binary search. However, binary search is only valid if the list is in sorted order. Average performance There are two cases: for searches that will fail because the value is not in the list, the search span must be successively halved until no more elements remain and this process will require at most the p probes just defined, or one less. This latter occurs because the search span is not in fact exactly halved, and depending on the value of N and which elements of the list the absent value x is between, the span may be closed early.

5 5 of 12 9/8/2010 6:37 PM For searches that will succeed because the value is in the list, the search may finish early because a probed value happens to match. Loosely speaking, half the time the search will finish one iteration short of the maximum and a quarter of the time, two early. Consider then a test in which a list of N elements is searched once for each of the N values in the list, and determine the number of probes n for all N searches. N = n/n = 1 3/2 5/3 8/4 11/5 14/6 17/7 21/8 25/9 29/10 33/11 37/12 41/ In short log 2 (N) 1 is about the expected number of probes in an average successful search, and the worst case is log 2 (N), just one more probe. If the list is empty, no probes at all are made. Suppose the list to be searched contains N even numbers (say, 2,4,6,8 for N = 4) and a search is done for values 1, 2, 3, 4, 5, 6, 7, 8, and 9. The even numbers will be found, and the average number of iterations can be calculated as described. In the case of the odd numbers, they will not be found, and the collection of test values probes every possible position (with regard to the numbers that are in the list) that they might be not found in, and an average is calculated. The maximum value is for each N the greatest number of iterations that were required amongst the various trail searches of those N elements. The first plot shows the iteration counts for N = 1 to 63 (with N = 1, all results are 1), and the second plot is for N = 1 to The curve for the "found" searches approaches log 2 (N) 1 more closely for larger N as larger numbers of iterations are involved, in the same way that the successive summations 1/2, 1/4 + 1/2, 1/8 + 1/4 + 1/2 approach 1 as the number of terms increases: these are the probabilities of early detection of equality in successive iterations of a search. The slight bend in the curves within each iteration limit group is due to the early narrowing of the search bounds into two sub-spans whose lengths are often unequal. Iteration count for 1 N < 64

6 6 of 12 9/8/2010 6:37 PM Thus binary search is a logarithmic algorithm and executes in O(logN) time. In most cases it is considerably faster than a linear search. It can be implemented using iteration (as shown above), or recursion. In some languages it is more elegantly expressed recursively; however, in some C-based languages tail recursion is not eliminated and the recursive version requires more stack space. Binary search can interact poorly with the memory hierarchy (i.e. caching), because of its random-access nature. For in-memory searching, if the span to be searched is small, a linear search may have superior performance simply because it exhibits better locality of reference. For external searching, care must be taken or each of the first several probes will lead to a disk seek. A common technique is to abandon binary Iteration count for 1 N < searching for linear searching as soon as the size of the remaining span falls below a small value such as 8 or 16 or even more in recent computers. The exact value depends entirely on the machine running the algorithm. Notice that for multiple searches with a fixed value for N, then (with the appropriate regard for integer division), the first iteration always selects the middle element at N/2, and the second always selects either N/4 or 3N/4, and so on. Thus if the array's key values are in some sort of slow storage (on a disc file, in virtual memory, not in the cpu's on-chip memory), keeping those three keys in a local array for a special preliminary search will avoid accessing widely separated memory. Escalating to seven or fifteen such values will allow further levels at not much cost in storage. On the other hand, if the searches are frequent and not separated by much other activity, the computer's various storage control features will more or less automatically promote frequently-accessed elements into faster storage. When multiple binary searches are to be performed for the same key in related lists, fractional cascading can be used to speed up successive searches after the first one. Inserting and deleting elements The main disadvantage of sorted arrays is that inserting and deleting random elements executes in O(N) time. This is not true in all cases however. The search algorithm can be changed to check the last element first, which allows loading a sorted list at O(1) time per element. Extensions There is no particular requirement that the array being searched has the bounds 1 to N. It is possible to search a specified range, elements first to last instead of 1 to N. All that is necessary is that the initialisation be L:=first

7 7 of 12 9/8/2010 6:37 PM 1 and R:=last + 1, then all proceeds as before. The elements of the list are not necessarily all unique. If one searches for a value that occurs multiple times in the list, the index returned will be of the first-encountered equal element, and this will not necessarily be that of the first, last, or middle element of the run of equal-key elements but will depend on the positions of the values. Modifying the list even in seemingly unrelated ways such as adding elements elsewhere in the list may change the result. To find all equal elements an upward and downward linear search can be carried out from the initial result, stopping each search when the element is no longer equal. Thus, e.g. in a table of cities sorted by country, we can find all cities in a given country. Several algorithms closely related to or extending binary search exist. For instance, noisy binary search solves the same class of projects as regular binary search, with the added complexity that any given test can return a false value at random. (Usually, the number of such erroneous results are bounded in some way, either in the form of an average error rate, or in the total number of errors allowed per element in the search space.) Optimal algorithms for several classes of noisy binary search problems have been known since the late seventies, and more recently, optimal algorithms for noisy binary search in quantum computers (where several elements can be tested at the same time) have been discovered. Variations There are many, and they are easily confused. Also, binary search vs. selection sort is debatable. Exclusive or inclusive bounds The most significant differences are between the "exclusive" and "inclusive" forms of the bounds. This description uses the "exclusive" bound form, that is the span to be searched is (L + 1) to (R 1), and this may seem clumsy when the span to be searched could be described in the "inclusive" form, as L to R. Although the details differ the two forms are equivalent as can be seen by transforming one version into the other. The inclusive bound form may be attained by replacing all appearances of "L" by "(L 1)" and "R" by "(R + 1)" then rearranging. Thus, the initialisation of L:=0 becomes (L 1):=0 or L:=1, and R:=N + 1 becomes (R + 1):=N + 1 or R:=N. So far so good, but note now that the changes to L and R are no longer simply transferring the value of p to L or R as appropriate but now must be (R + 1):=p or R:=p 1, and (L 1):=p or L:=p + 1. Thus, the gain of a simpler initialisation, done once, is lost by a more complex calculation, and which is done for every iteration. If that is not enough, the test for an empty span is more complex also, as compared to the simplicity of checking that the value of p is zero. Nevertheless, the inclusive bound form is found in many publications, such as Donald Knuth. The Art of Computer Programming, Volume 3: Sorting and Searching, Third Edition. Deferred detection of equality Because of the syntax difficulties discussed below, so that distinguishing the three states <, =, and > would have to be done with two comparisons, it is possible to use just one comparison and at the end when the span is reduced to zero, equality can be tested for. The example distinguishes only < from >=. Midpoint and width An entirely different variation involves abandoning the L and R pointers in favour of a current position p and a width w where at each iteration, p is adjusted by + or w and w is halved. Professor Knuth remarks "It is

8 8 of 12 9/8/2010 6:37 PM possible to do this, but only if extreme care is paid to the details" Section 6.2.1, page 414 of The Art of Computer Programming, Volume 3: Sorting and Searching, Third Edition, outlines an algorithm, with the further remark "Simpler approaches are doomed to failure!" Computer usage The algorithm Although the basic idea of binary search is comparatively straightforward, the details can be surprisingly tricky Professor Donald Knuth When Jon Bentley assigned it as a problem in a course for professional programmers, he found that an astounding ninety percent failed to code a binary search correctly after several hours of working on it [3], and another study shows that accurate code for it is only found in five out of twenty textbooks (Kruse, 1999). Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contains an error that remained undetected for over twenty years. [4] Numerical difficulties In a practical implementation, the variables used to represent the indices will be of finite size, hence only capable of representing a finite range of values. For example, 16-bit unsigned integers can only hold values from 0 to If the binary search algorithm is to operate on large arrays, this has two implications: The values first 1 and last + 1 must both be representable within the finite bounds of the chosen integer type. Therefore, continuing the 16-bit example, the largest value that last may take is , not A problem exists even for the "inclusive" form of the method, as if x > A(65535).Key, then on the final iteration the algorithm will attempt to store into L and fail. Equivalent issues apply to the lower limit, where first 1 could become negative as when the first element of the array is at index zero. If the midpoint of the span is calculated as p := (L + R)/2, then the value (L + R) will exceed the number range if last is greater than (in our example) 65535/2 and the search wanders toward the upper end of the search space. This can be avoided by performing the calculation as p := (R - L)/2 + L. For example, this bug existed in Java SDK at Arrays.binarySearch() from 1.2 to 5.0 and fixed in 6.0 [5]. Syntax difficulties Another difficulty is presented by the absence in most computer languages of a three-way result from a comparison, which forces a comparison to be performed twice. The form is somewhat as follows: if a < b then action1 else if a > b then action2 else action3; About half the time, the first test will be true so that there will be only one comparison of a and b, but the other half of the time it will be false, and a second comparison forced. This is so grievous that some versions are recast so as not to make a second test at all thus not determining equality until the span has been reduced to zero, and thereby foregoing the possibility of early termination remember that about half the time the search will happen on a matching value one iteration short of the limit.

9 9 of 12 9/8/2010 6:37 PM It is quite easy to make this problem still worse (e.g. as in [6] ) by using an order such as if a = b then action3 else if a > b then action2 else action1; Rather than detecting equality early (as it might appear to), this will force two comparisons to be performed for all but the last iteration of a search. Implementations Iterative The following algorithm is slightly modified (to avoid overflow) from Niklaus Wirth's in Standard Pascal [7] : min := 1; max := N; {array size: var A : array [1..N] of integer} repeat mid := min + ((max - min) div 2); if x > A[mid] then min := mid + 1 else max := mid - 1; until (A[mid] = x) or (min > max); This code uses inclusive bounds and a three-way test (for early loop termination in case of equality), but with two separate comparisons per iteration. It is not the most efficient solution. Three-way comparison Since Fortran does offer a three-way test, here is a version for searching an array of integers. For labels Fortran uses numbers at the start of statements, thus the 1, 2, 3, and 4. The if statement performs a go to to one of the three nominated labels according to the sign of its arithmetic expression. Integer Function BinarySearch(A,X,N)! Search for the value X in A(1)..A(N) Integer A(*),X!The array is indexed 1 to? Integer N!Stated number of elements. Integer L,R,P L = 0!Exclusive bounds, R = N + 1!To search elements 1 to N. 1 P = (R - L)/2!Probe; integer division. Not (L + R)/2! if (P <= 0) Return(-L)!Search exhausted. P = L + P!Convert an offset from L to an array index. if (X - A(P)) 3,4,2!Test: negative,zero,positive. 2 L = P!A(P) < X. Shift the left bound up. go to 1 3 R = P!X < A(P). Shift the right bound down. go to 1 4 Return(P)!X = A(P). Found at index P. End Function BinarySearch Recursive

10 10 of 12 9/8/2010 6:37 PM The most straightforward implementation is recursive, which recursively searches the subrange dictated by the comparison: BinarySearch(A[0..N-1], value, low, high) { if (high < low) return -1 // not found mid = low + ((high - low) / 2) if (A[mid] > value) return BinarySearch(A, value, low, mid-1) else if (A[mid] < value) return BinarySearch(A, value, mid+1, high) else return mid // found } It is invoked with initial low and high values of 0 and N-1. We can eliminate the tail recursion above and convert this to an iterative implementation: Single comparison per iteration In computer languages that lack a three-way comparison, the required three-way comparison has to be replaced by two two-way comparisons that would on average involve one and a half comparisons per iteration, not one. To reduce this overhead, some implementations defer checking for equality until after the search completes, as in this pseudocode: low = 0 high = N while (low < high) { mid = low + ((high - low) / 2) if (A[mid] < value) low = mid + 1; else //can't be high = mid-1: here A[mid] >= value, //so high can't be < mid if A[mid] == value high = mid; } // high == low, using high or low depends on taste if ((low < N) && (A[low] == value)) return low // found else return -1 // not found This approach foregoes the possibility of early termination on discovery of a match, thus successful searches have log 2 (N) iterations instead of an expected log 2 (N) 1 iterations. On the other hand, this implementation makes fewer comparisons: log 2 (N) is less than the expected number of comparisons for the two-test implementations of 1 5(log 2 (N) 1), for N greater than eight. Language support Many standard libraries provide a way to do a binary search: C provides bsearch(3) ( in its standard library. C++'s STL provides algorithm functions binary_search, lower_bound and upper_bound. Java offers a set of overloaded binarysearch() static methods in the classes Arrays ( and Collections ( /util/collections.html) in the standard java.util package for performing binary searches on Java arrays and on collections with indexed random access, respectively. They must be arrays of

11 11 of 12 9/8/2010 6:37 PM primitives, or the arrays or Lists must be of a type that implements the Comparable interface, or you must specify a custom Comparator object. Microsoft's.NET Framework 2.0 offers static generic versions of the Binary Search algorithm in its collection base classes. An example would be System.Array's method BinarySearch<T>(T[] array, T value). Python provides the bisect ( module. COBOL can perform binary search on internal tables using the SEARCH ALL statement. Perl can perform a generic binary search using the CPAN module Search::Binary ( /perldoc?search::binary). See also Index (information technology) Very fast 'lookup' using an index to directly select an entry Branch tables Alternative indexed 'lookup' technique for decision making Self-balancing binary search tree Run-time analysis, illustrating binary search technique on machines of differing speeds Bisection method, the same idea used to solve equations in the real numbers References ^ Introduction to Algorithms, [1] ( pp15 ^ ^ Bentley, Jon (2000) [1986]. Programming Pearls (2nd edition ed.). Addison-Wesley. p. 34. ISBN ^ Extra, Extra Read All About It: Nearly All Binary Searches and Mergesorts are Broken ( Google Research Blog ^ Bug ID: (coll) binarysearch() fails for size larger than 1<<30 ( /view_bug.do?bug_id= ) ^ [2] ( ^ Niklaus Wirth: Algorithms + Data Structures = Programs. Prentice-Hall, 1975, ISBN [3] ( Donald Knuth. The Art of Computer Programming, Volume 3: Sorting and Searching, Third Edition. Addison-Wesley, ISBN Section 6.2.1: Searching an Ordered Table, pp Kruse, Robert L.: "Data Structures and Program Design in C++", Prentice-Hall, 1999, ISBN , page 280. Netty van Gasteren, Wim Feijen. The Binary Search Revisited ( /wf214.pdf), AvG127/WF214, (investigates the foundations of the Binary Search, debunking the myth that it applies only to sorted arrays) External links NIST Dictionary of Algorithms and Data Structures: binary search ( /binarysearch.html) Google Research: Nearly All Binary Searches and Mergesorts are Broken ( Binary search implemented in 12 languages ( Retrieved from "" Categories: Search algorithms

12 12 of 12 9/8/2010 6:37 PM This page was last modified on 4 September 2010 at 02:52. Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details. Wikipedia is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.