对于使用最小堆优先级队列的 Dijkstra 实现,我将其设置为查找网络上不存在的站,以便它必须检查所有内容。我的问题是,由于总时间复杂度 # PSEUDOCODE
1. INIT QUEUE & DICTIONARY WITH DISTANCE TO SOURCE BEING INF
2. ENQUEUE SOURCE WITH DISTANCE 0
3. SET DISTANCE TO SOURCE FOR SOURCE TO 0
4. LOOP WHILE QUEUE NOT EMPTY
a. POP STATION FROM QUEUE (CALL IT P)
b. IF P MARKED AS VISITED THEN RESTART LOOP (CONTINUE).
c. IF P == TARGET RETURN DIST
d. LOOP THROUGH ALL ADJACENT STATIONS (A) TO P
i. IF (A IS NOT MARKED AS VISITED) AND (DIST TO P + DIST(P,A) < DIST TO A)
1. CHANGE DIST TO A TO BE THE NEW DIST
2. PUSH A ONTO THE PRIORITY QUEUE.
,为什么网络查找到一个站点的最小距离所花费的时间在具有 500 个边和 400 个站点的网络中不存在,而站点的长度大于一个具有 500 个边的站点和 500 个站?
注意:所有站点至少通过 1 条边相连。带 |E| 的站= |S| + 100 有 100 个额外的边,它们是唯一的但随机连接的
getCircleRectangleDisplacement
答案 0 :(得分:2)
@Arne 是对的,这个问题很大程度上取决于所使用的实际图表。
|E| = |S|形成一个非常非常稀疏的图。我们举一个极端的例子。假设你有 |S| = 500, |E| = 500,所有节点整齐排列成一个圆圈。在每次迭代时,算法会:
一直以来,PQ 都在接近空运行。 PQ 是对常规队列的一种优化,但如果队列中只有一个节点,那么优化的空间并不多。当您知道 N 始终为 1 时,就没有必要谈论 O(log N)。实际性能比 Big-Oh 表示法预测的最坏情况性能要好得多。
现在添加 100 条边。突然间,算法有了选择! PQ 填满。假设检查的第一个节点有 10 条边,因此 PQ 的大小为 10。它可能会在几十次迭代中保持这个大小。 PQ 终于有工作要做了!这就是额外时间消耗的来源。
附言是 Dijkstra,不是 Djikstra。
答案 1 :(得分:0)
我想当你说
<块引用>为什么网络查找到一个站点的最小距离所花费的时间在具有 500 个边和 400 个站点的网络中不存在比具有 500 个边和 500 个站点的网络长?
您并不是说这对于具有规定数量的节点和边的任何一对图都是正确的(因为它不是),而只是对于您构造的一对特定的图实例和已测试。
另一方面,时间复杂度语句给出了具有给定节点和边数的任何图实例的一般上限。换句话说,这是一种最坏的情况,即使对于算法最难快速处理的一个令人讨厌的图也是如此。
所以没有矛盾。您只是碰巧选择了图实例,其中较小的图实际上使算法更难发现没有路径。不管这个例子如何,对于具有 400 个节点(和 500 条边)的最坏可能图,该算法仍然比具有 500 个节点(和 500 条边)的最差可能图更快。