neighbors about xgi

[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 #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.