Deal with sink nodes somehow

[alexpghayes]

Options:

• Do something about them
• Ignore them silently
• Ignore them with a warning

Important to document this because otherwise the, for example, igraph PPR and the aPPR PPR numbers don't match up. Also results in weird circumstances where you visit all nodes in a graph (consider a -> b -> c as an entire graph), but sum(p) << 1. This seems somewhat concerning to me.

[fchen365]

This is what I did in the old time (also the current heck for targeted sampling), when a sink node is found: (i) delete such node. (ii) return r and p value to the seed. This way, sum(p) and sum(r) remain legit. (iii) send out a warning.

[alexpghayes]

Would you be willing to write up the version of Algorithm 3 with these changes? I'm not quite following from the verbal description, and it would be good to include the "modified" version in a vignette as part of the package documentation anyway. i.e. adding something likes to the follow that describe what happens when the for loop is empty

[fchen365]

This makes sense. I will try to do this next week.

[alexpghayes]

Hmmm is there something better than deleting sink nodes? If you have a graph a -> b -> c -> d -> e this will eventually result in deleting the whole graph.

[alexpghayes]

Also does it make more sense to return p and r to the seed, or to the currently visited node u?

[fchen365]

Hmmm is there something better than deleting sink nodes? If you have a graph a -> b -> c -> d -> e this will eventually result in deleting the whole graph.

open to suggestion. although these nodes are often less of our interest after all.

Also does it make more sense to return p and r to the seed, or to the currently visited node u?

The seed. We know we want to delete the node only when we actually select and query the node. So, currently, u is the sink one.