Train BlogCatalog without weighing positive/negative errors in adjacency reconstruction loss

[wehlutyk]

This tests if the poor adjacency reconstruction we're seeing in #31 comes from the weighing of losses.

[wehlutyk]

The changes made in 3bba9c8fdd5afd66a593a61bf8473b8f794e28fb and 92e08273786a6c3fc1a5e2f8d9358223a74c78fc are for this issue and need to be reverted afterwards. It's now training on grunch, and will be done in about 24h.

[wehlutyk]

(Rerunning as the script picked up the wrong version of the nw2vec package, hardlinked by the environment, instead of the local blogcatalog branch... Back in about 24h)

[wehlutyk]

Done, needs a results notebook.

[wehlutyk]

Results are in f2f38d34917803f88cc1482954c241f2c001493f, see the projects/scale/blogcatalog-dim_ξ=10-no_adj_cross_entropy_weighing-results.ipynb notebook. This change make a big difference!!

Highlights:

• adjacency reconstruction loss goes very close to 0, down from 4000 (on the same scale) in previous runs (#31, #41)
• the adjacency reconstruction itself is still pretty bad: its density is closer to what it should be, but still much too high, and it still doesn't have the right qualitative look. But at last, it's worth comparing to the best that can be done with the vanilla GAE (#44) as it's finally a result that looks plausible (and it's possible that the model can't learn better, maybe, maybe not).
• it might be useful now to look back at up-weighing the adjacency loss, and/or implementing the correctness changes of #7.

[wehlutyk]

So this means we're not reverting 3bba9c8fdd5afd66a593a61bf8473b8f794e28fb and 92e08273786a6c3fc1a5e2f8d9358223a74c78fc.