neighbors

[iaciac]

I was thinking that, when doing simulations (particularly for games), it is very useful to have the neighbors of a node divided by hyperedge. To explain better, here's what the current neighbors function returns:

hyperedge_list = [[1, 2], [2, 3, 4]]
H.neighbors(2)
# {1, 3, 4}

which is basically the neighbors in the graph projection of H. What I was imagining is actually a higher-order neighbor function that returns {[1], [3, 4]}. This is extremely useful in loops when you want to scroll over the hyperedges attached to a node and then the neighbors in those.

Do you think something like this could be integrated into the current neighbors function? Or maybe two different ones? In my old code I had H.graph_neighbors() and H.neighbors().

[leotrs]

Agree this would be nice. This sounds like the higher-order version of an egonet, no? So perhaps we can have H.neighbors and H.egonet or something like that.

[nwlandry]

I like this idea! I also tried to do something similar in another repo of mine (line 126). I would vote to create a dedicated function for this initially, and then if it becomes clear that we can have a single function, then that's great. Renaming to follow your convention is cool with me as well!

[leotrs]

To move this forward we need a consensus on the name. Current alternatives are:

1. Rename the current function (returns all neighbors in a single list) to graph_neighbors and the new one would be neighbors.

2. Current function remains as neighbors and new one is called egonet.

3. Something else.

Please vote!

[iaciac]

Obviously, let's start a third option :D

3. Keep this exact function with the name neighbor_nodes. Then, to get what I was proposing one could simply use the membership function discussed in Interface of NodeView #40 and from there it would be straightforward.

What do you think?

[maximelucas]

Our reasoning to call it neighbor_nodes instead of neighbor is to make it explicit that it returns node IDs (and not edge IDs).

[leotrs]

In that case I would also suggest a neighbor_edges then.

Also, I think returning the edges a node is part of (its membership) vs returning the edges it is a part of but with that node removed are sufficiently different that they could be different methods. So this would leave suggestion number 3 as implementing neighbor_nodes and neighbor_edges, both returning lists of ids, and membership and egonet, returning lists of edges.

....which perhaps seems like overkill? Not sure

[leotrs]

Perhaps a good compromise is to implement only two functions: members and membership and have them take one parameter, ids, which controls whether they return a list of ids or a list of objects.