-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loopy belief propagation #42
Comments
I remember this paper (https://arxiv.org/pdf/1705.08415.pdf) mentioned this problem and propose to do GNN on line graph. On line graph, m_{uv} and m_{wu} are connected nodes. The idea is to maintain two GNNs. On the line graph GNN, it computes the summation of m_{uv}. On the normal graph, it computes the summation of x. The two GNNs need to cooperate by state sharing (currently just manually set/get reprs). |
Just a side note: the official implementation simply builds for each edge a list of indices of all the incoming edges, stored in an integer Tensor. The indices start from 1, with 0 for a "dummy" edge whose message is always a zero vector. The update phase then simply involves an embedding lookup in message tensor with the index tensor, followed by a sum. @jermainewang For this reason, I don't think a line graph is necessary for most cases involving such kind of loopy belief propagation (though I'm not sure if line graph could be a more general solution). Also, the line graph deduced from the bidirectional graph would still include a connection for every |
Re official implementation: I'm not sure what you meant by saying "edge features are variable length vector". All the message vectors have the same number of elements. While each edge does have a variable number of incoming messages, they solve the problem by padding with a dummy edge whose message is always a zero vector, so that the number of incoming messages become the same. This idea only works for reducing with Re line graph: I see. A small caveat is that such a construction differs from |
For now, I guess I'll stick to the line graph approach. But it seems to me that this will introduce a non-negligible overhead, particularly due to the construction of another A more elegant approach would be to define some other primitives that support edge-to-edge (or message-to-message) updates, but I'm not sure how to do that, and I'm reluctant to have other primitive(s) added solely for loopy BP. I wonder if there is any other solution... |
Would it suffice by putting a filter on message reduction? |
We decided that doing message passing on line graph (specifically, the line graph without feedback from itself; see Joan's paper above) is a more general solution. |
The loopy belief propagation updates messages on a directed edge
![gif](https://user-images.githubusercontent.com/2978100/43998005-7ec26e32-9db9-11e8-8b74-46980988e8fc.gif)
![gif](https://user-images.githubusercontent.com/2978100/43998033-14c9dc12-9dba-11e8-9d5a-2c7cdbaaee3c.gif)
e = (u, v)
by looking at the messages on all edges pointing tou
, except the one that comes fromv
. An example from Junction-Tree VAE looks like this:where
m
's are messages,x
are input features andW
are weights (the latter two should be fine).The readout would be something like
and the output vector being the average of all
h_u
's.I can't think of a direct way to do loopy belief propagation like this within the current framework.
A possible workaround for this particular phase I can think of is to divide the process into two stages, maintaining a field called
:
msg_sum
, containing the sum of incoming message for each nodem_uv
like this:As you can see, this require us to query the message on the reverse edge, which I wonder if is possible. AFAIK the message function does not allow you to look at edges other than the ones to be updated.
s_u
as the sum of all incomingm_uv
.s_u
to compute theh
's.Any ideas?
The text was updated successfully, but these errors were encountered: