我想知道是否有人可以提供一些关于如何在图表上执行深度优先搜索时检查钻石依赖关系的指示...我有以下图表A -> B, A -> F, B -> C, B-> E, C -> D, E -> D
。
我正在尝试构建一个代表指定图形的容器,但是当我达到钻石依赖时,我不知道该怎么做。例如,在我的图表中,C
和E
都是B
的子容器,当我解析D
时,我需要引用C
和{{ 1}}。我可以检测钻石依赖关系并将E
和C
合并到一个容器中吗?
答案 0 :(得分:3)
我发现最容易想到使用颜色的图算法。
所有节点都以白色开始。
正在处理的节点显示为灰色。
处理完一个节点后,将其涂成黑色。
您在遇到节点后立即将其着色为灰色。
在处理完子节点后,将节点着色为黑色。
如果遇到黑色节点,那么你就会遇到钻石依赖。
答案 1 :(得分:2)
Rohan你可以使用深度优先搜索来通过查找交叉或前沿来检测“diamond-deps”。如果你看一下boost-graph-library主页上depth-first-search的伪代码实现。
... 否则如果(color [v] = BLACK) (u,v)是交叉或前沿 ...
答案 2 :(得分:0)
我不知道你是如何定义图表的节点的。让我们说一种表示节点的方法如下 -
public interface Node {
int getValue();
List<Node> getChildren();
}
这种实现的问题是 - 我们不知道一个Node的父节点。如果我们有办法知道谁是一个节点的paretent,我们可以找出钻石依赖。
例如,在你的情况下,我们应该从树的底部开始,我们可以看到D有两个Parenets,它们来自B. 所以我会说建立你的图表不仅照顾childerns而且照顾父母。然后在一次传递中,确定哪些节点有多个父节点(如D有)以及这些节点网(C和E)是否具有相同的父节点(B)。
答案 3 :(得分:0)
我不确定你要做什么,但最迟当你的图表包含循环时,你真的需要检测你在搜索过程中反复找到的节点。通常这是通过在处理节点时以某种方式标记节点来完成的,这样您以后可以看到之前是否已经访问过它们。在您的情况下,它的工作情况取决于您的实现以及这些节点的外观......
答案 4 :(得分:0)
也就是说,依赖解决问题是合法的。
答案 5 :(得分:-1)
图论是一个非常庞大而复杂的数学领域。这是一些知识可能是危险的事情之一:)即使是图论的基本应用,也很难找到简单的解释。机会非常好,任何你可能遇到的图表已被打死,并且有5倍的陷阱和陷阱,然后你想象可能会遇到问题。
我猜你会在这里看到一些非常合理的建议,然后稍后它们将被识别为部分甚至大多数错误。小心一点。