是否有python函数返回列表中未出现的第一个正整数？

Question

I'm tryin to design a function that, given an array A of N integers, returns the smallest positive integer (greater than 0) that does not occur in A.

This code works fine yet has a high order of complexity, is there another solution that reduces the order of complexity?

Note: The 10000000 number is the range of integers in array A, I tried the sort function but does it reduces the complexity?

def solution(A):
    for i in range(10000000):
        if(A.count(i)) <= 0:
            return(i)

Answer 1

The following is O(n logn) :

a = [2, 1, 10, 3, 2, 15]

a.sort()
if a[0] > 1:
  print(1)
else:
  for i in range(1, len(a)):
    if a[i] > a[i - 1] + 1:
      print(a[i - 1] + 1)
      break

If you don't like the special handling of 1 , you could just append zero to the array and have the same logic handle both cases:

a = sorted(a + [0])
for i in range(1, len(a)):
  if a[i] > a[i - 1] + 1:
    print(a[i - 1] + 1)
    break

Caveats (both trivial to fix and both left as an exercise for the reader):

• Neither version handles empty input.
• The code assumes there no negative numbers in the input.

Answer 2

O(n) time and O(n) space:

def solution(A):
    count = [0] * len(A)
    for x in A:
       if 0 < x <= len(A):
          count[x-1] = 1  # count[0] is to count 1
    for i in range(len(count)):
        if count[i] == 0:
           return i+1
    return len(A)+1  # only if A = [1, 2, ..., len(A)]

Answer 3

This should be O(n). Utilizes a temporary set to speed things along.

a = [2, 1, 10, 3, 2, 15]
#use a set of only the positive numbers for lookup

temp_set = set()
for i in a:
    if i > 0:
        temp_set.add(i)

#iterate from 1 upto length of set +1 (to ensure edge case is handled)
for i in range(1, len(temp_set) + 2):
    if i not in temp_set:
        print(i)
        break

Answer 4

My proposal is a recursive function inspired by quicksort.

Each step divides the input sequence into two sublists (lt = less than pivot; ge = greater or equal than pivot) and decides, which of the sublists is to be processed in the next step. Note that there is no sorting.

The idea is that a set of integers such that lo <= n < hi contains "gaps" only if it has less than (hi - lo) elements.

The input sequence must not contain dups. A set can be passed directly.

# all cseq items > 0 assumed, no duplicates!
def find(cseq, cmin=1):
    # cmin = possible minimum not ruled out yet
    size = len(cseq)
    if size <= 1:
        return cmin+1 if cmin in cseq else cmin
    lt = []
    ge = []
    pivot = cmin + size // 2
    for n in cseq:
        (lt if n < pivot else ge).append(n)
    return find(lt, cmin) if cmin + len(lt) < pivot else find(ge, pivot)


test = set(range(1,100))
print(find(test)) # 100
test.remove(42)
print(find(test)) # 42
test.remove(1)
print(find(test)) # 1

Answer 5

Inspired by various solutions and comments above, about 20%-50% faster in my (simplistic) tests than the fastest of them (though I'm sure it could be made faster), and handling all the corner cases mentioned (non-positive numbers, duplicates, and empty list):

import numpy

def firstNotPresent(l):
    positive = numpy.fromiter(set(l), dtype=int) # deduplicate
    positive = positive[positive > 0] # only keep positive numbers
    positive.sort()
    top = positive.size + 1
    if top == 1: # empty list
        return 1
    sequence = numpy.arange(1, top)
    try:
        return numpy.where(sequence < positive)[0][0]
    except IndexError: # no numbers are missing, top is next
        return top

The idea is: if you enumerate the positive, deduplicated, sorted list starting from one, the first time the index is less than the list value, the index value is missing from the list, and hence is the lowest positive number missing from the list.

This and the other solutions I tested against (those from adrtam , Paritosh Singh , and VPfB ) all appear to be roughly O(n), as expected. (It is, I think, fairly obvious that this is a lower bound, since every element in the list must be examined to find the answer.) Edit: looking at this again, of course the big-O for this approach is at least O(n log(n)), because of the sort. It's just that the sort is so fast comparitively speaking that it looked linear overall.