为什么Graph邻接不被定义为邻接集，而是邻接列表？

Question

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

这是我能想到的专业人士。

1. 作为Set属性，图表可以提供重复边缘的保证以及 Set 的许多其他属性。此外，来自Set Theory的所有设置操作变得可用，这对于分析更直观。如：

   • vertex_set_A | vertex_setB是联合行动。
   • vertex_set_A & vertex_set_B，是交叉操作。

2. *意见，Set更容易理解，因为它在数学校对中具有相关性。它还提供了低级代码处理数组和内容的良好抽象。

3. 在性能方面，可以使用HashSet实现来提供恒定的时间操作。当图表需要在日志时间操作中频繁动态更改时，或者TreeSet。
4. 列表数据结构还维护元素的排序属性，这在大多数图形中没有用处。事实上，列表以有序的方式迭代，这不应该首先发生。索引订购无关紧要，而Set可以提供。订购重要的唯一时间是图表被加权，因此基于权重的排序，其中TreeSet主要在日志时间操作。

所以，我不确定为什么大多数图算法只提到邻接列表。是因为Set难以实施的技术障碍，而List更容易吗？

Answer 1

这确实是一个很好的问题，事实上还没有一个全面的答案，只是将问题再重复一遍，“为什么不”确实如此。

评论中的理由对我来说似乎更像是凑合的借口，因为这只是历史上一直存在的，仍然不足以证明真正的理由。

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

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

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

如果您的应用程序适合它，当然可以继续使用它。
我的教科书也使用了它们。

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