when convert to dgl graph, new item'id about eges HOT 5 CLOSED

Oh I see. This encoding process is indeed wrong. I fixed this part in this commit. You can pull the latest code from master.

from eges.

And if you want to compute new node (node id that didn't shown in the whole graph), new node's base embedding will not be found. Thus you can only get new node's embedding via its side-information.

from eges.

If you run with the default arguments, the num_skus = len(sku_encoder) after graph construction using session will be 1006, which means there are total 1006 nodes (already encoded as [0, 1005] by sku_encoder) in the graph. And the model will use this num_skus to init nodes' base embeedings: base_embeds = th.nn.Embedding(num_nodes, dim). So the embedding number should be equal to the len(sku_encoder).

from eges.

Oh, I confused with https://github.com/dmlc/dgl/tree/master/examples/pytorch/eges.

The sku_encoder has 1006 nodes(items) encoded, and when making g through add_sessions, the items 73, 1000, 1001 are dropped. so in g has nodes that are relabeled from 1006 nodes to 1003 nodes. by being shifted and densified.

model's base_embeds is th.nn.Embedding(1006, dim=8).

so, encoded items : 0~1005(1006), g's items : 0 ~ 1002(1003).

Q1. because dataloader is set by range(1003)(which is range of g's nodes when dataloader declaration), model uses only 1003 embeddings in base_embeds. right?
Q2. if I want to use encoded items(0 ~ 1005)' embeddings in other task, do I have to convert g's item index back to encoded item index (g item index -> newtorkx graph's item index)?

from eges.

Thank you so much for this discussion and good tip 😃

from eges.