[DISCUSSION] Potential confusion for accessing edges

[dmlc]

[DISCUSSION] Potential confusion for accessing edges

[jermainewang]

But this can be a bit confusing as one might wonder what if I want to

access two edges with edge ids. I think we should have more docs. The syntax is well-defined. We should fix syntax that has ambiguity, but I didn't see any for this case.

…

On Sat, Nov 24, 2018, 11:55 AM Mufei Li ***@***.***> wrote: In the doc for dgl.DGLGraph, it says that we can access the edges with either g.edges[src, dest] <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jermainewang_dgl_blob_master_python_dgl_graph.py-23L118&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=TjZkSg9Jv2ODj9HXvCAcwgw9aSXPP3jh5bcRbCbUO5s&m=9FtzINdajyCspj2_YBuhKYyYpsXXSBiYMAc1GLyujag&s=d1SqlR3qxCwxgdfBzJgfsYbmE4n3sUevDrb7oZaQIJE&e=> or g.edges[edge_id] <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jermainewang_dgl_blob_master_python_dgl_graph.py-23L127&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=TjZkSg9Jv2ODj9HXvCAcwgw9aSXPP3jh5bcRbCbUO5s&m=9FtzINdajyCspj2_YBuhKYyYpsXXSBiYMAc1GLyujag&s=bFHPtOc42V4MvdqIj14r-pZUrg64VXLgCbEwb1bKUxE&e=> for a single edge. But this can be a bit confusing as one might wonder what if I want to access two edges with edge ids. Although careful users will realize that we only allow accessing multiple edges by edge ids through a list of edge ids, this is just confusing. Perhaps we should just forbid using a single int for edge id to access the related edge and require the users to consistently use a list of ints for edge ids? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jermainewang_dgl_issues_173&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=TjZkSg9Jv2ODj9HXvCAcwgw9aSXPP3jh5bcRbCbUO5s&m=9FtzINdajyCspj2_YBuhKYyYpsXXSBiYMAc1GLyujag&s=vzh04pTrWCe-5YpvffCNj76dXFeTMlV3q0zGJ9i2_fU&e=>, or mute the thread <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AD3qZTR3Dvh6HDkB142GkowY26p4OLVWks5uyXoDgaJpZM4YxgKo&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=TjZkSg9Jv2ODj9HXvCAcwgw9aSXPP3jh5bcRbCbUO5s&m=9FtzINdajyCspj2_YBuhKYyYpsXXSBiYMAc1GLyujag&s=2v0FJCBxI_Ncoj3vbkfI_Xz_x2Ii-cCGXwGDsFYWgp8&e=> .

[mufeili]

Well, my point is that if we do g.edges[0, 1], users may wonder whether we are accessing the edge with src 0 and dest 1 or accessing two edges with edge ids 0 and 1.

[jermainewang]

I think this is our job of educating users. We should tell user that g.edges returns a view (same as networkx). The view object contains two convenient overloads:

• __getitem__ to access data of the given edge(s).
• __call__ to access all the edge ids.

g.edges[0, 1] is equivalent to g.edges.__getitem__((0, 1)) (in accordance with python). As a result, g.edges[0, 1] accesses one edge (0, 1).

list type is introduced in DGL to express multiple nodes/edges at once, which usually raises TypeError in normal container overload. Hence, accessing two edges at once should be g.edges[[0, 1]].

The rules are:

• tuple type is reserved to represent edge with two endpoints. (for example, we should not allow g.edges[0, 1, 2]. That will be really confusing.).
• list and tensor types are used to represent multiple node/edge ids.

[jermainewang]

Also, since __call__ is defined for g.edges. g.edges() will return the edge ids (in uv or eid). This also comes from the practice of networkx.

[mufeili]

Alright, I will mention it in the doc.