为什么图的邻接不是定义为邻接集，而是定义为邻接表？答案

【问题标题】：Why Graph adjacency is not defined as adjacency set, but rather adjacency list?为什么图的邻接不是定义为邻接集，而是定义为邻接表？
【发布时间】：2017-01-08 15:04:48
【问题描述】：

在图论中，我们知道顶点邻接可以使用邻接表数据结构来表示。相反，邻接集在图论的任何地方都没有被广泛提及。为什么会这样？

这是我能想到的优点。

作为Set属性，图可以在重复边和Set的许多其他属性方面提供保证。此外，来自Set Theory 的所有设置操作都变得可用，这更直观地用于分析。如：
- vertex_set_A | vertex_setB 是联合操作。
- vertex_set_A & vertex_set_B，是交集运算。
*意见，Set 更容易理解，因为它在数学证明中具有相关性。它还很好地抽象了低级代码如何处理数组和东西。
在性能方面，可以使用 HashSet 实现，这将提供恒定时间操作。或者 TreeSet 当图表需要在日志时间操作上频繁动态变化时。
列表数据结构还维护元素的排序属性，这在大多数图形中没有用处。事实上，列表以有序的方式迭代，这本来就不应该发生。 Indexed Ordered 应该无关紧要，Set 可以提供这一点。排序重要的唯一时间是图被加权时，因此基于权重的排序，其中 TreeSet 主要在日志时间操作中运行。

所以，我不确定为什么大多数图形算法只提到邻接表。是不是因为技术壁垒，Set 更难实现，而List 更容易实现？

【问题讨论】：

adjacency matrix 也很常见。列表的优点是它也可以表示重复的边。这在一组中是不可能的。
@AxelKemper，是的，我知道，但在图算法中，一般邻接矩阵是最糟糕的数据结构。（我主要指的是一般的经典算法）。 stackoverflow.com/questions/2218322/…
您的问题可能会导致基于意见的答案。什么是“好”，什么是“坏”数据结构？你的标准是什么？在性能和简单性方面，矩阵有其优点。缺点是占用空间。列表很容易获得，而且可能比集合更容易实现。
@AxelKemper 为什么你首先要表示重复的边。在 Set 中，具有相同端点的 2 条边不应被视为重复，而应视为单独的实体
没有特定理由使用列表而不是集合。但是，该列表有一些论据。列表可以以比集合更紧凑的方式实现（就内存布局而言）。最值得注意的是，它提供了内存一致性。迭代一个简单的列表比迭代一个集合（最常见的操作）更快。对于大多数应用程序，您提到的功能没有相关性。像集合操作这样的东西仍然可以用一个辅助集合来实现（无论如何你都需要它来获得结果）。事实上，在大多数情况下，列表可以被视为数学集合的实现。

标签： algorithm list graph set

【解决方案1】：

这确实是一个非常好的问题，事实上没有一个全面的答案，只是再次重复这个问题，“为什么不”确实。

cmets 中的原因对我而言似乎更像是虚构的借口，因为这只是历史上一直存在的东西，仍然不足以证明一个真正的原因。

列表只是一个通用标签，如果它更适合您的任务，您可以（并且应该）使用集合。

有些人会争辩说，该集合并没有为您提供有保证的 O(1) 查找时间 - 它是摊销的，即使非常不可能，最坏的情况仍然是 O(n)，其他人会通过列表推断更快的迭代，并且然后是关于实施可行性的争论。

虽然它们在技术上没有错，但我并不真正相信其中任何一个是主要原因。
我认为真正的原因是它们被使用 “只是因为惯例”强>。
一般标签是“列表”，而且它的字面意思经常被使用，以至于失去了它的通用性。

当然，如果您的应用程序适合它，请继续使用一组。
我的教科书也用过。

（哦，当我说“应用程序借给它”时，还有一个例子来驱动那个回家；如果您需要在应用程序中经常查找入度，该集合将为您提供 O(V) 运行时，其中 V 表示数字顶点，邻接列表将为您提供 O(E) 运行时，其中 E 表示边数。对于密集图，假设不允许平行边，O(E) 往往会变为 O(V^2)。因此，邻接集将给出你在这里有更好的运行时性能。）

【讨论】：

你用的是什么教材？
您能否在您的回答中澄清您所说的实施可行性是什么意思？
@heretoinfinity 我指的是“Parallel Scientific Computation - A Structured Approach Using BSP”一书，但可以在here 找到更易于理解的示例。关于“实施可行性”，我指的是作者关于“技术障碍”的评论和乔尔·比芬对上述问题的评论。