置换查找器算法分析(伪码)

时间:2010-07-22 13:22:17

标签: c# algorithm optimization hash random

关于生成所有排列的SO post让我想到了一些替代方法。我正在考虑使用空间/运行时权衡,并且想知道人们是否可以在尝试用C#实现它时批评这种方法和可能的打嗝。

步骤如下:

  1. 给定同构元素的数据结构,计算结构中元素的数量。

  2. 假设排列由结构的所有元素组成,请计算步骤1中值的阶乘。

  3. 实例化<key(Somehashofcollection),Collection<data-structure of homogeneous elements>>类型的较新结构(词典)并初始化计数器。

  4. 哈希(???)步骤1中的种子结构,并将哈希和集合的键/值对插入到词典中。将计数器增加1。

  5. 随机改组(???)种子结构的顺序,哈希,然后尝试将其插入到步骤3的词典中。

  6. 如果哈希中存在冲突,请再次重复步骤5以获取新订单并散列并检查是否存在冲突。成功插入后,将计数器增加1。

  7. 重复步骤5&amp; 6直到计数器等于步骤2中计算的阶乘。

  8. 使用某种随机函数(这对我来说是一个黑盒子)似乎这样做可能有助于在淫秽大小的数据集的适当时间范围内获得所有排列。

    很高兴从SO的伟大思想中获得一些反馈,以进一步分析这种方法,其目的是偏离在这种性质的算法中普遍存在的传统蛮力方法,以及使用这种方法实现这种算法的影响C#。

    由于

2 个答案:

答案 0 :(得分:1)

使随机化生成的排列顺序似乎是一种复杂的方法。就时间效率而言,你不能比“暴力”方法做得更好。

答案 1 :(得分:1)

与标准的已知方法相比,这种产生所有排列的方法并不好。

假设您有n个项目且M = n!排列。

这种生成方法有望在发现所有M之前产生M * lnM排列。

(有关可能的解释,请参阅此答案:Programing Pearls - Random Select algorithm

此外,哈希函数是什么?对于合理的散列函数,我们可能不得不很快开始处理非常大的整数问题(肯定是n> 50,不记得确切的截止点)。

此方法也耗尽了大量内存(所有排列的哈希表)。

即使假设散列是完美的,这种方法也会采用预期的Omega(n M logM)操作并保证Omega(nM)空间,而标准的众所周知的方法可以在O(M)中实现)时间和O(n)空间。

作为一个起点,我建议人们可以阅读:Systematic Generation of All Permutations相信是O(nM)时间和O(n)空间,并且仍然比这种方法好得多。

请注意,如果必须生成所有排列,任何算法都必须采用Omega(M)步骤,因此上面提到的方法是最佳的!