add_nodes and add_edges leave graph_indicator inconsistent on batched graphs
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
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 小时
- 30 天内合并 PR
- 10
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
JuliaGraphs/GraphNeuralNetworks.jl 的其他 Issue
-
GNNLux MEGNetConv drops the state of stateful sublayers可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭lux
难度 2/5 1-3 小时 新手友好度 76/100
JuliaGraphs/GraphNeuralNetworks.jl#732 ·
维护者通常 2 天内回复
-
Unused output of node type leads to index error in Zygote可能已有人在做 @lenianiva 于 2 天前认领。 未关闭
难度 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 于 4 天前认领。 未关闭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 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
FluxML/Metalhead.jl#407 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
-
难度 1/5 1 小时以内 新手友好度 88/100
SciML/ModelingToolkit.jl#5371 ·
维护者通常 2 天内回复
-
query handling with arrays has changed between 1.x and 2.x可能已有人在做 @rehmansaeed06-byte 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复