EncodeProcessDecode model documentation

[ferreirafabio]

Hi,
I've been trying to understand the EncodeProcessDecode model parameters, however, the documentation is a little scarce on the parameters (edge_output_size, node_output_size, global_output_size) in this case.

In the code I found the following comment # Transforms the outputs into the appropriate shapes. but that doesn't clarify the exact reshaping. Can anybody clarify?

Thanks a lot!

[vbapst]

The EncodeProcessDecode model will output a graph with parametrizable features sizes on the dges, nodes globals. The edge_output_size represents the size of the edge feature that you will have on the output of your model. Similarly, node_output_size represents the size of the node feature in your output graph.

Internally, this module first encode the graph with fixed size feature (defined in make_mlp_model), then apply the core network for num_processing_steps steps (cf. the _build method of EncodeProcessDecode), and then decodes it to the desired shapes.

[ferreirafabio]

Thank you! Just to clarify:
if I have n nodes and each node has a feature vector of shape (d,), then node_output_size would be n*d?

[vbapst]

If you specify node_output_size = d, then your output graph will contain a node fields of shape [n, d].

[ferreirafabio]

got it now, thank you for your time!

[ferreirafabio]

I was wondering what would happen if nodes vary in their feature sizes. I assume under current code conditions they all have to be padded to have the same size?

[alvarosg]

The short answer is yes, since the graph network treats all nodes equally (except for the actual values of their features), so the MLPs (or other models) that process nodes and edges, have to assume a fixed size.

However, you should think carefully about how you do the padding. For examples: lets say you have nodes of two types, with a set of shared features (x_i), but some some features that are specific to each node type (y_i, and z_i):
type_1_features: (x_1, x_2, y_1, y_2)
and the other type has features:
type_2_features: (x_1, x_2, z_1)

In this case you would probably do the padding as:
type_1_features: (x_1, x_2, y_1, y_2, 0)
and the other type has features:
type_2_features: (x_1, x_2, 0, 0, z_1)

so the shared features are aligned and the non-shared features have their own slots.

Additionally, you may want to include a one hot encoding of the type of nodes to help the network reason about the different node types, so the final features would look like:

In this case you would probably do the padding as:
type_1_features_padded: (1, 0, x_1, x_2, y_1, y_2, 0)
and the other type has features:
type_2_features_padded: (0, 1, x_1, x_2, 0, 0, z_3)

In some cases, if you have many node types, and each of them have their own different features, you may not be able to afford having different slots for the different features. In these cases it should be good enough to just pad with zeros at the end, and let the network use the one-hot encodings to do the reasoning.

[ferreirafabio]

That helped. Appreciate the response!