Editing Brute-force search (section)

==Reordering the search space==
In applications that require only one solution, rather than all solutions, the [[expected value|expected]] running time of a brute force search will often depend on the order in which the candidates are tested. As a general rule, one should test the most promising candidates first. For example, when searching for a proper divisor of a random number ''n'', it is better to enumerate the candidate divisors in increasing order, from 2 to {{nowrap|''n'' − 1}}, than the other way around{{snd}}because the probability that ''n'' is divisible by ''c'' is 1/''c''. Moreover, the probability of a candidate being valid is often affected by the previous failed trials. For example, consider the problem of finding a '''1''' bit in a given 1000-bit string ''P''. In this case, the candidate solutions are the indices 1 to 1000, and a candidate ''c'' is valid if ''P''[''c''] = '''1'''. Now, suppose that the first bit of ''P'' is equally likely to be '''0''' or '''1''', but each bit thereafter is equal to the previous one with 90% probability. If the candidates are enumerated in increasing order, 1 to 1000, the number ''t'' of candidates examined before success will be about 6, on the average. On the other hand, if the candidates are enumerated in the order 1,11,21,31...991,2,12,22,32 etc., the expected value of ''t'' will be only a little more than 2.More generally, the search space should be enumerated in such a way that the next candidate is most likely to be valid, ''given that the previous trials were not''. So if the valid solutions are likely to be "clustered" in some sense, then each new candidate should be as far as possible from the previous ones, in that same sense. The converse holds, of course, if the solutions are likely to be spread out more uniformly than expected by chance.