Notes from the changelog

[maelle]

From #2058 reading https://github.com/igraph/igraph/blob/develop/CHANGELOG.md

• The R package does not use igraph_setup(), should it do so somehow?
• Changes in error codes: maybe we will notice that in the test snapshots.

[maelle]

igraph_edges() gained a new bycol argument that determines the order in which the edges are returned. bycol = false reproduces the existing behaviour, while bycol = true returns the edges suitable for a matrix stored in column-wise order.

I ran the test file of "interface.R" and found no error.

[szhorvat]

igraph_edges() gained a new bycol argument that determines the order in which the edges are returned. bycol = false reproduces the existing behaviour, while bycol = true returns the edges suitable for a matrix stored in column-wise order.

I ran the test file of "interface.R" and found no error.

For historical reasons, there's both igraph_get_edgelist() and igraph_edges(), which fulfil more or less the same function. We decided to keep both in 1.0. I expect the R interface relies on igraph_get_edgelist() so changes to igraph_edges() may not be causing any issues.

Here's another tip:

Changes to low-level functions that deal with core data structures (and converting to graphs to forms that are typically used internally, such as adjlist) are likely to only affect non-generated C core in rinterface_extra.c. How do you know if a function is "low level"? There's no certain way but the general guideline is that it does NOT appear in functions.yaml. (In this particular case, igraph_edges() does appear there though!)

High level functions do appear in functions.yaml and will affect R code.

[maelle]

#2098

[maelle]

• igraph_attribute_handler_t members that formerly took an untyped igraph_vector_ptr_t argument are now taking a typed igraph_attribute_record_list_t argument instead.

That I don't know what to do with, what are "igraph_attribute_handler_t members"?

[maelle]

• igraph_neighbors() and igraph_vs_adj() gained two extra arguments to specify what to do with loop and multiple edges. This makes their interfaces consistent with igraph_adjlist_init().

The two new arguments are igraph_loops_t loops, igraph_bool_t multiple https://igraph.org/c/html/develop/igraph-Basic.html#igraph_neighbors

#2099
#2151

@szhorvat's rec: "Recommendation: Do not auto-generate vs/es functions."

[maelle]

• igraph_incident() and igraph_es_incident() gained an extra arguments to specify what to do with loop edges. This makes their interfaces consistent with igraph_inclist_init().

The new argument is igraph_loops_t loops.

#2100

[maelle]

• igraph_is_simple() gained an extra igraph_bool_t argument that decides whether edge directions should be considered. Directed graphs with a mutual edge pair are treated as non-simple if this argument is set to IGRAPH_UNDIRECTED (which treats the graph as if it was undirected).

This is not documented @szhorvat? At least I see no difference between https://igraph.org/c/html/develop/igraph-Structural.html#igraph_is_simple and https://igraph.org/c/html/0.10.16/igraph-Structural.html#igraph_is_simple

[maelle]

• The type of the loops argument of igraph_adjlist_init_complementer(), igraph_centralization_degree(), igraph_centralization_degree_tmax(), igraph_degree(), igraph_maxdegree(), igraph_sort_vertex_ids_by_degree() and igraph_strength() was changed to igraph_loops_t from igraph_bool_t, allowing finer-grained control about how loop edges are treated.

#2101

[maelle]

• igraph_distances(), igraph_distances_cutoff(), igraph_get_shortest_path(), igraph_get_shortest_paths() and igraph_get_all_shortest_paths() gained a weights argument. The functions now automatically select the appropriate implementation (unweighted, Dijkstra, Bellman-Ford or Johnson) algorithm based on whether weights are present and whether there are negative weights or not. You can still call the individual methods by their more specific names.

Not documented? https://igraph.org/c/html/develop/igraph-Structural.html#igraph_distances

The functions are already auto-generated.

[maelle]

• The weighted variants of igraph_diameter(), igraph_pseudo_diameter(), igraph_radius(), igraph_graph_center(), igraph_eccentricity() and igraph_average_path_length() were merged into the undirected ones by adding a new argument named weights in the second position.

rigraph/src/rinterface_extra.c

Line 4016 in 90be8d9

SEXP R_igraph_diameter(SEXP graph, SEXP pdirected, SEXP punconnected,

calls igraph_diameter_dijkstra at the moment.

Do the autogeneration switch on the next branch since the develop branch of the C library is needed. #2110

a046f43

[maelle]

• The semantics of the igraph_permute_vertices() permutation argument has changed: the i-th element of the vector now contains the index of the original vertex that will be mapped to the i-th vertex in the new graph. This is now consistent with how other igraph functions treat permutations and vertex index vectors; for instance, you can now pass the result of igraph_topological_sorting() directly to igraph_permute_vertices() to obtain a new graph where the vertices are sorted topologically.

• As a consequence to the change in the semantics of the igraph_permute_vertices() permutation argument, the semantics of the permutations returned from igraph_canonical_permutation() and igraph_canonical_permutation_bliss() have also been inverted to maintain the invariant that the output of these functions can be fed into igraph_permute_vertices() directly.

Maybe relevant.

[maelle]

• igraph_motifs_randesu_no() and igraph_motifs_randesu_estimate() now take an igraph_real_t as their result argument to prevent overflows when igraph is compiled with 32-bit integers.

#2152

[maelle]

• igraph_erdos_renyi_game_gnm() gained a multiple Boolean argument to uniformly sample G(n,m) graphs with multi-edges.

• igraph_bipartite_game_gnm() gained a multiple Boolean argument to uniformly sample bipartite G(n,m) graphs with multi-edges.