NodeView supports accessing the edge ids that contain a node in three different ways:

H = some_hypergraph()
H.nodes[1] == H.nodes(1) == H.members(1)
# -> True

I find this unpythonic. I'd much rather there was a single way of doing things if at all possible. If there was exactly one way of accessing the edges that contain a node, which would you prefer? If anyone can argue that we should support two (or more) ways of doing the same thing, I'm all ears.

Related to #20.

Currently,

H.edges 
# EdgeView([3, 2, 4, 9])

outputs edge ids, not edges as list of member nodes. It's often useful to access edges as list of member nodes. One current way is list(H._edge.values()) but it's long and hidden.

Should we have a two views?

• EdgeIdView (to replace current EdgeView): for ids

H.edges_id
# EdgeIdView([3, 2, 4, 9])

• EdgeView:for list of member nodes

H.edges
# EdgeView([[0], [3, 4], [4], [4]])

Graph generators may sometimes return hypergraphs with isolated nodes (e.g. ER hypergraph with small p). In these cases, and others, it is usual to obtain the largest component. Ideally, we would like to do something like this:

G = xgi.erdos_renyi_hypergraph(n, m, p).largest_component()
G = xgi.erdos_renyi_hypergraph(n, m, p).remove_isolates()

The current functionality only specifies the number of hyperedges to which a node belongs. In principle, one should be able to specify a hyperedge size or list of sizes and it returns the number of hyperedges of that size of which that node is a part.

All these functions do very similar things. In keeping with the idea of doing things only once, I vote we simplify them somehow.

I personally lean toward the nuclear option and just keeping shape. All the others are not necessary...

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().

When calling the .nodes property, cProfile indicates that every time that H.nodes is called, a new object is constructed (the hypergraph for which this profile was run has 2261 nodes): This shouldn't happen with the Lazy View construction. The same thing happens with calling H.edges

Fixes #28.

Demo:

H = xgi.Hypergraph([[1, 2, 3], [3, 4], [4, 5, 6]])

H.edges
# -> EdgeView((0, 1, 2))
H.edges.members()
# -> [[1, 2, 3], [3, 4], [4, 5, 6]]
H.edges.members(dtype=dict)
# -> {0: [1, 2, 3], 1: [3, 4], 2: [4, 5, 6]}

This is an addition to the view interface. Essentially, now we can do the following:

H = xgi.Hypergraph([[1, 2, 3], [3, 4], [4, 5, 6]])

# filter nodes by degree
H.nodes
# -> NodeView((1, 2, 3, 4, 5, 6))
H.nodes(degree=2)     # awesome new stuff
# -> NodeView((3, 4))

# filter edges by order
H.edges
# -> EdgeView((0, 1, 2))
H.edges(order=2)     # whoa
# -> EdgeView((0, 2))

# awesome stuff happens
1 in H.edges
# -> True
1 in H.edges(order=2)     # magic
# -> False

Using H.nodes(degree) or H.edges(order) return view objects that contain only a subset of nodes or edges. These are still instances of the same old view classes. The difference is that now IDView contains a list of IDs that it keeps track of. So it will always contain the entire dictionary and attributes of all nodes/edges, just like before, but now whenever it reads from them, it uses the provided subset of IDs that it is keeping track of. This is probably going to be a pain in the ass later on because whenever we add or change functionality of IDView, we will need to remember to use the subset of ids, and not the keys of the stored dictionary which would be more natural.

One technical comment is that I had to implement the class method IDView.from_view to create a new view from a different view. This is because the constructor of NodeView and EdgeView take only a hypergraph, so we didn't have a way of creating a view from a view.

One drawback of the current implementation is that the views no longer preserve order. In particular, I had to change all the tests that use views from lists to sets. So that made the diff a little messy.

Finally, in the process of writing this I found a bug in how json hypergraphs were being read. The specified nodetype was not being respected. This is now fixed.

I'm moving the conversation from #32 to here.

The current is a proof of concept. We just have to agree on the name and whether we want an analogous method for edges. Once we agree on that, I'll implement those and add tests.

Demo:

In [6]: H = xgi.Hypergraph([(0,1,2), (1,2), (0, 3)])

In [7]: H.neighbors(0)
Out[7]: {1, 2, 3}

In [8]: H.egonet(0)
Out[8]: [[1, 2], [3]]

In [9]: H.egonet(0, include_self=True)
Out[9]: [[0, 1, 2], [0, 3]]

Closes #32.

• Add a function which allows you to specify a list of nodes and an option to shrink edges (false if you want an induced subhypergraph) and it will return the subhypergraph.
• Add a function which allows you to specify a list of edges and it will return the subhypergraph.

I wanted to easily visualize the degree/edge size distribution and the way that I found easiest to get both was the following:

degrees = dict(H.degree())
edge_sizes = dict(H.edge_size())

d, count_d = np.unique(list(degrees.values()), return_counts=True)
p_d = count_d/len(degrees)
e, count_e = np.unique(list(edge_sizes.values()), return_counts=True)
p_e = count_e/len(edge_sizes)

Currently, there is a way to do some of this with degree_histogram, but I would like to be able to a) specify either edge sizes or degrees and b) specify whether it is normalized. And perhaps we should return numpy arrays instead of lists.

The current method returns all edges a node belongs to. This is not called the egonet, it should be called something else. The egonet includes edges among nodes that are neighbors of the specified node.

The base classes are already bloated as it is, so we should try to do some cleanup. I propose the base classes only keep methods that directly modify the underlying structure. All other methods should go to auxiliary classes. For example:

These should move to NodeView:

• isolates
• neighbors

These should move to EdgeView:

• singleton_edges (and rename to singletons)
• max_edge_order (and rename to max_order)
• duplicate_edges (and rename to duplicates)
• is_possible_order (do we really need this method?)

For example, instead of H.neighbors, we would do H.nodes.neighbors. Yes this is longer but I think it's worth it. Maintenance, documentation, and end-user code will be better.

These methods should be removed completely:

• get_edge_data (data can be accessed via View objects)
• has_edge (do n in H.edges instead)
• has_node (do n in H.nodes instead)

remove_simplex_id enforces removing all subfaces as well and calls remove_simplex_ids_from to do so. Because of this, remove_simplex_ids_from does not enforce simpliciality. I think that remove_simplex_ids_from should call remove_simplex_id and either

1. Implement the contents of remove_simplex_ids_from directly in remove_simplex_id
2. rename remove_simplex_ids_from to be a helper function.

so that calling remove_simplex_id in remove_simplex_ids_from is not circular.

• Added jupytext as a dependency in the tutorials requirements file.
• Converted the tutorials to MyST (markdown) files
• Removed the Jupyter notebooks
• Provided a brief description for how to convert between markdown and Jupyter notebooks.