reticula-network / reticula Goto Github PK

Add simple joint-degree sequence functions, returning the degree-pairs of both ends. Maybe use those in *_degree_assortativity functions.

Maybe define a generic attribute_pairs function similar to definition of attribute_assortativity and go from there?

https://github.com/arashbm/dag/blob/9ae21521101c332a336b496a45a8f0fe5e741ee7/include/dag/algorithms.hpp#L11

Currently some functions use integer seeds, while some others use a mix of std::mt19937 and std::mt19937_64. The code should allow the use of a generic pseudo-random generator or at least use one uniformly, which is bad for reproducibility and backwards compatibility reasons.

It also should probably be renamed into dag::relabel_vertices, providing a variant that takes a vector/mapping of labels.

Make a random_number_distribution concept since standard library still doesn't supply one.

Use generic hash struct instead of hard-coding std::hash<> in dag::utils::unordered_hash and dag::utils::combine_hash. Default to std::hash.

currently the test only checks number of nodes and edges. It should check that the two graphs are isomorphic, but the hypothetical dag::is_isomorphic function doesn't exist yet.

Maybe worth checking out automorphism algorithms at the same time.

Currently BA or ER network generators are declared like undirected_network<VertT> ba_random_graph(size_t n, size_t m, std::mt19937_64& generator); and undirected_network<VertT> gnp_random_graph(size_t n, double p, std::mt19937_64& generator);. Why not use VertT instead of size_t for number of nodes n (and also number of new links m for BA)?

Take the following example:

d = ret.random_directed_expected_degree_sequence_hypergraph[ret.int64]([(2, 2)]*200000, [(5,5)]*80000, random_state=state)

It produces an edge with zero vertices, and many edges with only in- or out-verts. Similarly, the undirected variant creates one zero-degree edge and many one-degree edges. What should we do about them?

Other libraries leave them be, although some produce many zero-degree edges that are distinguished by an edge id.

Say you need to have floating-point weights for one of your weight sequences. Getting the edge and vertex weight sequence sums to exactly add up is quite impossible. The same story should be true for random expected directed dyadic graph with in- and out-weight sequences.

The total weight equality check should at minimum be less strict and maybe even just a warning. A large discrepancy is usually a sign of user error, but small differences are negligible.

Some functions, e.g. _deterministic_out_component() in src/temporal_component_sizes.tpp use cutoff_dt() member of the adjacency_prob, while others, e.g. implicit_event_graph<EdgeT, AdjacencyProbT>::predecessors_vert() uses a hardcoded value of 1e-20. The first function is used in in_component() and the second one in in_components(). What's the deal here?

Make sure Distribution and ResDistribution churn out something that is castable to EdgeT::TimeType in random_events(). Possibly through a requires clause.

add edge_*_degree and edge_*_degree_sequence functions for parity with vertex degree function.

dag::graph_union(g1, g2) copies one graph and merges the other one into the copy before returning it. Currently the one with the larger number of vertices is selected. Investigate if selecting based on number of edges or some other criteria might be better.

Generalise random_events() by relying on return type of static_projection() of EdgeT.

Possibly needs a new constructor for temporal edges from static edge and time?

The function name in deceleration does not match the definition. Make sure examples and tests are all correct.

Add edge_*_assortativity() for parity with vertex *_assortativity() functions.

libstdc++ would try to cache hash values unless the hash function is marked as noexcept and __is_fast_hash<hasher> returns true, which is the default. This might have some performance and memory use impact.