Open felipemello1 opened 3 years ago
It's named as g.edges()
now...
could you try https://docs.dgl.ai/generated/dgl.reverse.html#dgl.reverse with order=srcdst
could you try https://docs.dgl.ai/generated/dgl.reverse.html#dgl.reverse with
order=srcdst
Hi @Rhett-Ying , thanks for getting back to me. I understand that I could use reverse, but I would have to pay attention to semantics issues 'user', 'plays', 'game' --> 'game', 'plays', 'user'
, and possibly speed issues.
I guess what I am thinking is that if DGL already has the edges sorted by 'dst', and getting hg.all_edges(order='dst)
is just a matter on changing a couple of lines inside of the code, it could be worthwhile.
How about uid, vid = hg.in_edges(hg.nodes('game'), etype='plays', form='uv')
?
uid, vid = hg.in_edges(hg.nodes('game'), etype='plays', form='uv')
@Rhett-Ying Wouldn't this limit the search for only 'in_edges' instead of all edges, or am I interpreting G.all_edges wrong?
for heterographs, a non-ambiguous etype name is required. for each non-ambiguous etype name, only one in/out ntype exists. so hg.in_edges
should works same as hg.edges()
.
🚀 Feature
When using G.all_edges, only 3 types of ordering are supported: None, 'eid', 'srcdst'. Request: Add the option order='dst', if it is easy to do so.
Motivation
I need to calculate:
But torch.unique is 20% of the computation of my whole function, and torch.unique_consecutive is 10x faster. torch.unique_consecutive assumes that the vector is already sorted, so if G.all_edges could already provide sorted vid at minimal cost, the function would be 18% faster.
Additional context
I couldn't find the documentation of G.all_edges in the website for versions after 0.6.x.