chore: Add tests

[krlmlr]

to make sure the upcoming igraph release doesn't break anything.

[krlmlr]

@Antonov548: Interesting things happen when this PR is run with the dev version of igraph. Example:

── Failure (test-data.R:104:3): macaque snapshot ───────────────────────────────
Snapshot of code has changed:
old[4:15] vs new[4:15]
    IGRAPH DN-- 45 463 -- 
    + attr: Citation (g/c), Author (g/c), shape (v/c), name (v/c)
    + edges (vertex names):
-    [1] V1 ->V2     V1 ->V3     V1 ->V3A    V1 ->V4     V1 ->V4t    V1 ->MT    
+    [1] V2    ->V1  V3    ->V1  V3A   ->V1  V4    ->V1  V4t   ->V1  MT    ->V1 
-    [7] V1 ->PO     V1 ->PIP    V2 ->V1     V2 ->V3     V2 ->V3A    V2 ->V4    
+    [7] PO    ->V1  PIP   ->V1  V1    ->V2  V3    ->V2  V3A   ->V2  V4    ->V2 
-   [13] V2 ->V4t    V2 ->VOT    V2 ->VP     V2 ->MT     V2 ->MSTd/p V2 ->MSTl  
+   [13] V4t   ->V2  VOT   ->V2  VP    ->V2  MT    ->V2  MSTd/p->V2  MSTl  ->V2 
-   [19] V2 ->PO     V2 ->PIP    V2 ->VIP    V2 ->FST    V2 ->FEF    V3 ->V1    
+   [19] PO    ->V2  PIP   ->V2  VIP   ->V2  FST   ->V2  FEF   ->V2  V1    ->V3 
-   [25] V3 ->V2     V3 ->V3A    V3 ->V4     V3 ->V4t    V3 ->MT     V3 ->MSTd/p
+   [25] V2    ->V3  V3A   ->V3  V4    ->V3  V4t   ->V3  MT    ->V3  MSTd/p->V3 
-   [31] V3 ->PO     V3 ->LIP    V3 ->PIP    V3 ->VIP    V3 ->FST    V3 ->TF    
+   [31] PO    ->V3  LIP   ->V3  PIP   ->V3  VIP   ->V3  FST   ->V3  TF    ->V3 
-   [37] V3 ->FEF    V3A->V1     V3A->V2     V3A->V3     V3A->V4     V3A->VP    
+   [37] FEF   ->V3  V1    ->V3A V2    ->V3A V3    ->V3A V4    ->V3A VP    ->V3A
and 2 more ...

* Run testthat::snapshot_accept('data') to accept the change.
* Run testthat::snapshot_review('data') to interactively review the change.

Can you confirm? Is the current dev version of igraph reversing source and target vertices for edges in some way?

[Antonov548]

Can you confirm? Is the current dev version of igraph reversing source and target vertices for edges in some way?

I will take a look. Thanks.

[krlmlr]

Introduced in igraph/rigraph@aa055c209 .

[krlmlr]

But this is just the trigger, probably not the root cause.

[Antonov548]

Introduced in igraph/rigraph@aa055c209 .

Yes, I think I know where is problem.
Restore pointer is not working properly for not directed graphs. Actually is there any function in igraph core to create graph from the from and to but not edgelist?

Because in igraph_add_edges function the order for from and to is different depending on values and directed property of graph.

CC: @szhorvat

[krlmlr]

Looks like we have this sorted out.

[szhorvat]

Actually is there any function in igraph core to create graph from the from and to but not edgelist?

No, there isn't.

---

I still don't quite understand why it is not possible (or why it is disadvantageous) to store a flat edgelist in the R-side igraph object. @krlmlr Could you please explain your reasoning again at tomorrow's meeting? It would be good to write down what versions of the igraph object exist, how the format upgrade mechanism works, and what constraints it imposes on potential future changes. We need to get this right, and have a clear (and documented) procedure for any future format changes. Part of the reason why there's so much confusion now is that the format change procedure wasn't documented from the get-go, so now we have to figure everything out from scratch.