Add ability to specify hyperdegree order about xgi HOT 9 CLOSED

I'm not sure I follow, what do you mean by "specify"? Are you talking about querying the hypergraph for the edges that a node is a member of?

from xgi.

What I meant by this is to give the option to return the number of hyperedges of size m of which that nodes is a part (the m-th order hyperdegree) in contrast to simply counting the number of hyperedges of which that node is a part (degree).

from xgi.

Ah I see, so we are talking about this:

H.degree(node)

and

H.degree(node, order=m)

and

H.degree(node, order={m1, m2, m3})

I like the first two. For the last one, what would be the return type?

from xgi.

Exactly. The most general case is the hyperdegree sequence where every node has a vector of the degrees of different order. So I would presume that instead of returning the degree sequence as a dictionary with integer/float values it would be a dictionary with dictionary or list values. The problem is that it's a bit awkward; the degree sequence is much easier to use as an array in my experience, but that seems to make most sense when you're looking at a single degree/order degree. Perhaps we could have three properties: (1) degree, (2) order degree where you specify the order, and (3) hyperdegree where it returns all the order degrees in the structure I mentioned. The only thing I'm worried about is having too many options.

from xgi.

Yeah, this is exactly what I was afraid of... I think that overloading the function to have several different return types is super awkward.

How about this:

H.degree(node)
# -> total number of edges the node belongs to

H.degree(node, order=m)
# -> number of edges of size m the node belongs to

H.degree(node, order={m1, m2, m3})
# -> dict {m1: n1, m2: n2, m3: n3} such that node belongs to ni edges of size mi

H.degree(node, order={m1, m2, m3}, type=dict)
# -> same as above

H.degree(node, order={m1, m2, m3}, type=array)
# -> array [n1, ..., n2, ... n3, ...] - note it could have tons of zeros

What do you think? I'm okay with the last one returning a different type than the others because the return type is explicitly being specified.

it would be a dictionary with dictionary or list values

Can you please share an example where the function would return a dict of dicts?

from xgi.

A few things:

• Right now, the Hypergraph class has node_degree and edge_degree methods. This is because it can be helpful to get the edge "degree" which is the edge size.
• The current call is H.node_degree(nbunch=None, weight=None), where nbunch specifies an index or a list of indices. If None, it computes the degree for every node. The weight specifies the edge property to use when computing a weighted degree. An example of the return types is

H.node_degree
# NodeDegreeView([0,1,2,3,4])
dict(H.node_degree)
# {0 : 2, 1 : 1, 2 : 7, 3 : 2, 4 : 1}
dict(H.node_degree(weight="weight"))
# {0 : 0.12, 1 : 1.1, 2 : 2.87, 3 : 2.2, 4 : 1}

If we add a third parameter "order", the output becomes

dict(H.node_degree(order={2,3,4}))
# {0 : {2 : 1, 3 : 0, 4 : 0}, 1 : {2 : 1, 3 : 3, 4 : 2}, 2 : {2 : 7, 3 : 4, 4 : 0}, 3 : {2 : 2, 3 : 0, 4 : 1}, 4 : {2 : 0, 3 : 1, 4 : 0}}

What I meant about it being easier to work with arrays was that it's easier to work with np.array([2, 1, 7 2, 1]) than {0 : 2, 1 : 1, 2 : 7, 3 : 2, 4 : 1} (for the first example).

I will try to implement what you've suggested and see how easy it is to use.

from xgi.

Thanks for clarifying. I totally forgot the library is using views 😅 I think the current implementation is fine except that maybe we can add a type=array parameter. What do you think?

from xgi.

I like this idea, but would like to brainstorm a bit more before implementing.

from xgi.

Okay. A quick thought: perhaps node_degree and edge_degree should not be properties
The constructor for the DegreeView class currently does not input the selected nodes, weight, or the order.

An alternative approach is to make node_degree a simple function that passes the weight and hyperdegree order into the constructor for the NodeDegreeView class. The disadvantage to this is that the user can't call it as H.node_degree and will always have to call it as H.node_degree(). I think this is why NetworkX doesn't pass arguments to the DegreeView constructor.

from xgi.