Add function to get list of edges (not edge ids) about xgi

[nwlandry]

Okay, this makes sense and I completely agree. Perhaps we can tackle this at the same time as the DegreeView? I'll create a branch called "views" to work on this issue.

[leotrs]

There's another possibility: what if the user wants a dictionary of ids and members?

H.edges_members()
# SomeKindOfView({3: [0], 2: [3, 4], ...})

[maximelucas]

Agreed, that can be useful sometimes. That's what H._edge currently outputs.
Could make it into a view too.
I still feel like have some simple function, in addition, that outputs just the list of list of nodes is often convenient?

[leotrs]

I still feel like have some simple function, in addition, that outputs just the list of list of nodes is often convenient?

Agreed! If we implement what I suggest here, the following would just return a list of lists:

H.edges().values()

[iaciac]

I might have a preference for a default view that looks like the one of networkx for consistency:

EdgeView([(1, 2), (2, 3)])

I obviously see the point of all the other solutions with IDs and the dict ids values, so I would totally implement those as well, but it would be nice for the default one (again, imho) to be as close as possible to the networkx one.

[leotrs]

I tend to agree. @nwlandry ?

[nwlandry]

Hmmmm. I hadn't thought about the EdgeView simply being an edgelist. Currently in convert.py, there is a to_hyperedge_list() and to_hyperedge_dict() function. These functions return lists and dicts respectively, not views, so it would be interesting to consider doing this.

The reason that I have both edge IDs and node IDs is so that nodes can quickly query the edges of which they are a part. How would you modify the EdgeView? Would it simply be that the underlying data would be a list of lists, not a dictionary of lists?

[iaciac]

The reason that I have both edge IDs and node IDs is so that nodes can quickly query the edges of which they are a part.

This is super useful, I agree. As I said, but that's just my very biased opinion :P, ideally, I'd like the default version to be comparable to networkx's. Then maybe an option there could return the entire dict?

[maximelucas]

Sure, I also totally understand the usefulness of having a view that returns edge IDs. That's why I suggested to have two Views in my original message: (i) one that returns the edge IDs (as currently), and (ii) one that returns the edges as a list of list of node IDs.

When typing H.edgesI feel like a user would expect to see (ii), and it would also be consistent with NetworkX. I would name it EdgeView for consistency.
That's why I just suggested in my original message to rename (i), currently called EdgeView and accessed with H.edges, to EdgeIDView, and access it with, say, H.edges_id.

(Returning a dict {edge_id : list_of_nodes} can be useful too, but we can already use your function to_hyperedge_dict() and it feels less urgent to me to a have simple function for it).

What do you think?

[leotrs]

I believe we still don't have a way to do this. So I propose the following:

H.edges
# -> EdgeView(...)

H.edges.members(edge_id)
# -> [members of the specified edge]

H.edges.members()
# -> [[members of edge 0], [members of edge 1], ...]
H.edges.members(dtype=dict)
# -> {0: [members of edge 0], 1: [members of edge 1], ...}

The first two already work. The third one is easy to implement.