Venue: ICLR 2020 Conference

Reviews:

final_score: rating: 3: Weak Reject
review_content: This paper extends the previous graph wavelet neural network with separate computation for low frequency and high frequency part. The idea is to bring the octave convolution in vision to the graph domain. Experiments on three benchmark node classification tasks show comparable performances as previous methods. 

Overall the paper is written in a coherent and self-contained way, where the paper clearly states the related work and the contribution of this newly proposed work. Also it is interesting to see that normalizing the diagonal filter, tying the weights for low/high frequency parts would make the generalization better. However, there are several major concerns with the paper:

1. The contribution is somewhat limited. The main component is based on GWNN. While the GWNN itself takes the full spectrum of basis already, the formulation in (8) and (9) should somehow capture the same information. I think the paper spends too much content on the reviews, while lacks the intuition or theoretical explanations of the proposed formulation. 

2. Having marginal improvement on the three benchmarks is not that interesting. Also given the results are mixed with other baselines, I think more experiments (e.g., on large graphs, or graph-level supervised tasks, etc.) are necessary to demonstrate the empirical gain using the proposed formulation. 

3. Regarding the experiments, is it true that d/n=0 and d/n=1 should have exactly the same results? 

4. In Figure 2, I guess d/n=0 should be reduced to the GWNN. But it seems the performance is different than GWNN on citeseer and cora. Why there’s such inconsistency, or did I miss anything? 
review_title: Official Blind Review #1

final_score: rating: 3: Weak Reject
review_content: This paper proposes to use octave convolution to learn a representation of a graph.
Typically, a learning on a graph is done either in a spatial domain or in a spectral domain.
A spectral domain based approach uses a eigenvalue decomposition form of a graph Laplacian (a symmetric matrix) and learning a filter that acts on the eigenvalue of a graph Laplacian while preserving eigenvectors of a graph Laplacian.
This architecture is called the graph convolutional network on a spectral domain.

This paper's main contribution is to adapt octave convolutional network's architecture to the usual graph convolutional network. While I believe that this is the first work on applying the idea behind octave convolutional network architecture, separating low and high frequency component in the learning stage, to graph convolutional network architecture, I cannot see a good motivation on why this architecture is good for learning on a graph.
A comprehensive study in the paper shows a better performance gain compared to the existing method, but it would be better if the gains were substantial or the authors presented a good motivation on why this architecture is good in some cases.

Overall, I think the paper is well-written, but I would suggest to present more meaningful justification why and when the octave GCN is better than the GCN.
review_title: Official Blind Review #3

final_score: rating: 6: Weak Accept
review_content: Despite reading the paper multiple times,  I am not sure I have the background to know whether what is written is significant or not. I'm aware of work on general semi-supervised learning and see the much better performance of this approach compared to things like label propagation, but cannot say for sure whether the idea is novel/significant.

One q for authors -- I don't understand the core component of the proposal, is the key ingredient that have different weighting between low vs high that causes the better performance on tasks ? or is that we have less dependencies across variables (as reflected in the computational costs) that gets the better performance ?
review_title: Official Blind Review #2

Meta-review: Two reviewers are negative on this paper while the other one is slightly positive. Overall, the paper does not make the bar of ICLR and thus a reject is recommended.
Decision: Reject