add_nodes and add_edges leave graph_indicator inconsistent on batched graphs
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Read GNNGraphs/src/transform.jl, focusing on add_nodes and add_edges, and compare their handling of graph_indicator with the remove_nodes fix in PR #717. Decide or confirm the intended semantics for assigning new nodes in a batched graph, then check that the indicator stays consistent and sorted. Done when the chosen behavior is documented and tests cover batched additions, including the reported examples.
索引モデルが issue の本文から書いたものです。
説明
add_nodes and add_edges (when the new edges reference nodes beyond num_nodes) increase num_nodes but pass g.graph_indicator through unchanged. On a batched graph this leaves graph_indicator shorter than num_nodes:
using GNNGraphs
g = batch([rand_graph(3, 4), rand_graph(4, 6)])
g.num_nodes, length(g.graph_indicator) # (7, 7)
g1 = add_nodes(g, 2)
g1.num_nodes, length(g1.graph_indicator) # (9, 7)
g2 = add_edges(g, [8], [1])
g2.num_nodes, length(g2.graph_indicator) # (8, 7)
The resulting graph is inconsistent, so functions relying on graph_indicator (e.g. unbatch, getgraph, graph-level pooling) are likely to misbehave or error on it. The relevant code is add_nodes and add_edges in GNNGraphs/src/transform.jl, which both build the new GNNGraph with g.graph_indicator.
It's not a one-line fix because the correct behavior is ambiguous: it's unclear which graph of the batch the new nodes belong to. Options:
- Add a keyword (e.g.
graph = ...) to assign the new nodes to an existing graph, extendinggraph_indicatoraccordingly (and keeping it sorted, whichunbatchrequires). - Allow the new nodes to be appended as a new graph.
- Throw an informative error for batched graphs (
g.num_graphs > 1) until the semantics are decided.
Found while reviewing #717, which fixes the same class of inconsistency for remove_nodes.
🧔♂️🤖 Assisted by AI
- 主要言語
- Julia
- スター
- 310
- フォーク
- 75
- 平均マージ
- 2日 15時間
- マージ済み PR（30日）
- 10
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
JuliaGraphs/GraphNeuralNetworks.jl のほかの issue
-
lux
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
JuliaGraphs/GraphNeuralNetworks.jl#732 ·
メンテナーはふだん 2 日以内に返信
-
Unused output of node type leads to index error in Zygote対応中かも @lenianiva が 1 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
JuliaGraphs/GraphNeuralNetworks.jl#731 ·
メンテナーはふだん 2 日以内に返信
-
maintainance
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
JuliaGraphs/GraphNeuralNetworks.jl#725 ·
メンテナーはふだん 2 日以内に返信
-
GCNConv fails to compile with Reactant - MethodError対応中かも @DHAKED440 が 3 日前に担当しました。 オープンgnnlib lux
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
JuliaGraphs/GraphNeuralNetworks.jl#710 ·
メンテナーはふだん 2 日以内に返信
-
flux gnngraphs gnnlib
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
JuliaGraphs/GraphNeuralNetworks.jl#702 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
JuliaGraphs/GraphNeuralNetworks.jl の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
erfinv(::Float16) and erfcinv(::Float16) are wrong for abs(x) <= 0.75 (erfinv(Float16(0)) == 0.2201)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
JuliaMath/SpecialFunctions.jl#571 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100