Closed khaledadel19 closed 5 years ago
Thanks for pointing out that issue. It is indeed good, that this if never worked from the beginning six years ago!
It is a bug!
We should remove private static HashMap<String, Node> findNode = new HashMap<String, Node>();
completely from the class as this static hashmap screws up things when using two graphs.
Either you do a pull request with the removed findNode field or I will do that in April, when I am back from vacations. @DiegoMoussallem what do you think?
The nodes are always added indeed, however, it does not affect AGDISTIS' quality performance because of the hashmap used in edu.uci.ics.jung.graph.DirectedSparseGraph;
replaces and not duplicates when the same node is added to the graph. We can do what you suggested @RicardoUsbeck because this "static" will screw up certainly when two graphs are in the game, but we can also fix it and check if we have some gain in terms of time-performance. We could try both options.
Thanks for your swift responses, I actually tried to activate this part. I noted that activating this check using static, causes issues even when working with only one graph, changes on the weights from one request (during HITS) affects the consequent requests if the same node is found.
Yes, that is why I would remove this HashMap and just keep the else part
should be fixed now.
Can someone, maybe @DiegoMoussallem make sure we get the same results as in the latest MAG paper?
Sure, I am going to check it and let you know. ;)
Checked, the same results are obtained with this commit.
Line 49 in BreadthFirstSearch checks for the existence of targetNode in findNode. However the key used in findNode is targetNode.getObject(). Same for line 50 in findeNode.get().