我的面试问题是这样的:

给定一个包含40亿个整数的输入文件,提供一种算法来生成一个文件中不包含的整数。假设您有1gb内存。如果你只有10mb的内存,你会怎么做。

我的分析:

文件大小为4×109×4 bytes = 16gb。

我们可以进行外部排序,从而知道整数的范围。

我的问题是,在已排序的大整数集中检测缺失整数的最佳方法是什么?

我的理解(看完所有答案后):

假设我们讨论的是32位整数,有232 = 4*109个不同的整数。

情况1:我们有1gb = 1 * 109 * 8位= 80亿位内存。

解决方案:

如果我们用一位表示一个不同的整数,这就足够了。我们不需要排序。

实现:

int radix = 8;
byte[] bitfield = new byte[0xffffffff/radix];
void F() throws FileNotFoundException{
    Scanner in = new Scanner(new FileReader("a.txt"));
    while(in.hasNextInt()){
        int n = in.nextInt();
        bitfield[n/radix] |= (1 << (n%radix));
    }

    for(int i = 0; i< bitfield.lenght; i++){
        for(int j =0; j<radix; j++){
            if( (bitfield[i] & (1<<j)) == 0) System.out.print(i*radix+j);
        }
    }
}

情形二:10mb内存= 10 * 106 * 8bits = 8000万bits

Solution: For all possible 16-bit prefixes, there are 216 number of integers = 65536, we need 216 * 4 * 8 = 2 million bits. We need build 65536 buckets. For each bucket, we need 4 bytes holding all possibilities because the worst case is all the 4 billion integers belong to the same bucket. Build the counter of each bucket through the first pass through the file. Scan the buckets, find the first one who has less than 65536 hit. Build new buckets whose high 16-bit prefixes are we found in step2 through second pass of the file Scan the buckets built in step3, find the first bucket which doesnt have a hit. The code is very similar to above one.

结论: 我们通过增加文件传递来减少内存。


为那些迟到的人澄清一下:这个问题,正如所问的,并不是说有一个整数没有包含在文件中——至少大多数人不是这么理解的。不过,评论线程中的许多评论都是关于任务的变化。不幸的是,把它引入评论线程的评论后来被它的作者删除了,所以现在看起来它的孤儿回复只是误解了一切。这很让人困惑,抱歉。


当前回答

假设“整数”表示32位:10mb的空间足以让您计算输入文件中有多少个数字,具有任何给定的16位前缀,对于所有可能的16位前缀,在一次通过输入文件。至少有一个桶被击中的次数少于216次。执行第二次传递,以查找该bucket中哪些可能的数字已经被使用。

如果它意味着超过32位,但仍然是有限的大小:执行上述操作,忽略所有恰巧落在(有符号或无符号;32位范围。

如果“integer”指的是数学整数:通读输入一次,记录你见过的最长数字中最大的数字长度。当你完成后,输出最大值加1是一个多一位的随机数。(文件中的一个数字可能是一个大于10mb的大字节,但如果输入是一个文件,那么您至少可以表示任何适合它的长度)。

其他回答

统计信息算法解决这个问题的次数比确定性方法少。

如果允许使用非常大的整数,则可以生成一个在O(1)时间内可能唯一的数字。像GUID这样的伪随机128位整数只会与集合中现有的40亿个整数中的一个发生碰撞,这种情况的概率不到640亿亿亿分之一。

If integers are limited to 32 bits then one can generate a number that is likely to be unique in a single pass using much less than 10 MB. The odds that a pseudo-random 32-bit integer will collide with one of the 4 billion existing integers is about 93% (4e9 / 2^32). The odds that 1000 pseudo-random integers will all collide is less than one in 12,000 billion billion billion (odds-of-one-collision ^ 1000). So if a program maintains a data structure containing 1000 pseudo-random candidates and iterates through the known integers, eliminating matches from the candidates, it is all but certain to find at least one integer that is not in the file.

对于10mb内存限制:

将数字转换为二进制表示形式。 创建一个二叉树,其中左= 0,右= 1。 使用二进制表示将每个数字插入树中。 如果已经插入了一个数字,则叶子将已经创建。

完成后,只需使用之前未创建的路径来创建所请求的数字。

40亿数字= 2^32,这意味着10 MB可能不够。

EDIT

优化是可能的,如果已经创建了两个末端叶并且有一个共同的父级,那么可以将它们删除,并且父级标记为不是解决方案。这减少了分支,减少了对内存的需求。

编辑II

没有必要完全构建树。只有在数字相似的情况下才需要构建深度分支。如果我们也砍掉树枝,那么这个解决方案实际上可能有效。

你不需要对它们排序,只需要重复划分它们的子集。

The first step is like the first pass of a quicksort. Pick one of the integers, x, and using it make a pass through the array to put all the values less than x to its left and values more than x to its right. Find which side of x has the greatest number of available slots (integers not in the list). This is easily computable by comparing the value of x with its position. Then repeat the partition on the sub-list on that side of x. Then repeat the partition on the sub-sub list with the greatest number of available integers, etc. Total number of compares to get down to an empty range should be about 4 billion, give or take.

正如Ryan所说,基本上,对文件进行排序,然后遍历整数,当一个值被跳过时,你就有了:)

EDIT at downvotes: OP提到文件可以排序,所以这是一个有效的方法。

老问题了,但我想知道“非功能性”需求。在我看来,应该给出一个线索——如果这个问题是在其他地方问的,而不是在一本书里,然后继续讨论所有的可能性的利弊。通常情况下,这似乎是在工作面试中问的,让我困惑的是,在不知道软要求的情况下,不可能给出一个明确的答案,即。“查找缺失的数字一定非常快,因为它一秒钟要使用x次。”

我想这样的问题或许可以给出一个合理的答案。

我将所有数字归并排序到一个新文件中,每个int使用4个字节。当然,一开始做起来会很慢。但是它可以用很小的内存量来完成(你不需要把所有内存都保存在RAM中) 使用二进制搜索检查数字是否存在于预排序文件中。因为每个值仍然是4个字节,这没有问题

缺点:

文件大小 第一次排序很慢——但只需要一次

优点:

查找起来非常快

这又是一个非常适合写书的问题。但我认为,当要解决的问题还不完全清楚时,在寻求单一的最佳解决方案时,这是一个奇怪的问题。