search

dmlc / dgl

Python package built to ease deep learning on graph, on top of existing DL frameworks.
http://dgl.ai
Apache License 2.0
13.55k stars 3.02k forks source link

[Feature Request] Flexible builtin functions #451

Closed VoVAllen closed 5 years ago

VoVAllen commented 5 years ago

🚀 Feature

Adapt basics tensor operation into dgl ecosystems by custom builtin functions.

Motivation

Current dgl only support SPMV with adjacency matrix, which might not be flexible enough.

For example,

Chebynet uses Laplacian matrix to substitute adjacency matrix,

AGNNConv uses a custom propagation matrix.

In DiffPool model, the pooled graph has a read value soft adjacency matrix to do further forward operation.

Alternatives

Do the tensor operation outside dgl. Such as get ndata and do the forward independently and put the data back to ndata. However, this let user jump out from dgl ecosystem, and prevent user benefiting from propagation only over a subset of graph (i.e. using send_and_revc) provided by dgl.

Welcome any comment and discussion.

jermainewang commented 5 years ago

Are these matrix similar to have a weight edge field and use src_mul_edge for message passing?

VoVAllen commented 5 years ago

At most case, src_mul_edge can cover the scenario. One infeasible case might be the AGNNConv propagation matrix calculation. src_mul_edge is not enough.

My main motivation is to investigate how many models would be hard to implement under current API. Especially incorporating with send_and_recv, executing the algorithm on a subgraph, which can be an advantage of dgl over other frameworks. (whole graph computation with tensor operation can be done outside dgl message passing as far as I know)

Also how will src_mul_edge be implemented?

jermainewang commented 5 years ago

At most case, src_mul_edge can cover the scenario. One infeasible case might be the AGNNConv propagation matrix calculation. src_mul_edge is not enough.

AGNNConv looks like operating on a full graph with attention weight on the edges. Am I right? If so, src_mul_edge is still enough. But since the graph is dense, it may not benefit from SPMM.

My main motivation is to investigate how many models would be hard to implement under current API. Especially incorporating with send_and_recv, executing the algorithm on a subgraph, which can be an advantage of dgl over other frameworks. (whole graph computation with tensor operation can be done outside dgl message passing as far as I know)

Also how will src_mul_edge be implemented?

src_mul_edge will map to one SPMM kernel if the edge feature is scalar type and the reducer is sum. Otherwise, it will first broadcast src node feature to edge space. Then, depending on whether the reducer is sum or not, it will either multiply it with incidence matrix to perform aggregation or fallback to degree bucketing.

jermainewang commented 5 years ago

@yzh119 I found you mentioned to have more flexible message function for different edge type. Could you elaborate a little bit here?