feat: expose align_layout() and add to layout_nicely() to align layout with axis automatically

[szhorvat]

This is for #1907

This needs more work, of course, but I very much hope that it could be part of the next release. Can you take it over @schochastics ? Even this one-liner change makes a big difference IMO.

It'd be even better if #1956 could be addressed at the same time.

CC @maelle

---

Examples

plot(make_ring(5))

plot(make_lattice(c(2,4)))

plot(make_graph(~ 1-2-3-1-4))

See some more example in igraph/igraph#2781

---

Further improvements I'd suggest

• Expose the alignment feature to users as align_layout() (or choose a better name, but I recommend not starting with layout_ to avoid confusion with functions that create layouts)
• Increase the iteration count for layout_with_fr() for small graphs only. It makes a notable improvement.
• layout_nicely() should identify forests/trees #1957

Fix #1957
Fix #1907

[szhorvat]

Yes, this is expected.

It doesn't always do well with layouts that are rotationally symmetric, such as a cycle graph, a complete graph, or an $n\times n$ grid. An $n\times m, n\ne m$ grid would be fine.

What the system does is that it attempts to align, and if the order parameter is too small (it'd be zero with a perfectly symmetric layout), it removes an edge and tries again. With a $C_4$ or a grid like this, what may happen is that the first step succeeds due to imperfections of the output from layout_with_fr(), and there is no need for a second try after an edge removal. If it succeeds, sometimes it aligns the corners, i.e. gives a 45 degree orientation, which is still better than something that's neither 0/90, nor 45.

A way to improve on this is to increase the iteration count in layout_with_fr(), even by as much as a factor of 10. This is more computationally costly, but I think it's worth doing for very small graphs, where good layout matters the most anyway.

[schochastics]

(Sorry I delete my comment because I got that this is intended)
@szhorvat please check

[szhorvat]

Once we have this in R, it'll be easier to experiment and we can get feedback from users. Then we can experiment with the threshold that controls when to remove an edge and try again.

One more comment here is that I believe this algorithm to be practically fast (it's linear time), but alignment is somewhat pointless for very large graphs. So it's okay to be safe and skip doing it for very large ones (e.g. above 1000 vertices).

[szhorvat]

Here's an example with $C_4$. Sometimes it's at 0 degrees, sometimes at 45, and a few times it completely fails. After increasing the iteration count, it still does both 0 and 45, but it is much less likely to fail completely.

[szhorvat]

Brainstorming a bit about the best interface:

How about adding an align parameter to all organic layouts, and setting it to TRUE by default? Or even just auto-aligning all organic layouts above a certain vertex count, without an option to disable this behaviour?

This is perhaps nicer than restricting this feature to layout_nicely()? It also resolves the issue with deciding what layouts to align (e.g. that trees don't need alignment).

[schochastics]

My opinion:
Leave it at layout_nicely() for now but expose align_layout() which this PR does.
Adding this tacitly to all layout functions is not a good idea because it removes the non-determinism which might confuse users. In the longrun, we probably should add an parameter (or an option?) that is either TRUE or FALSE (for backward compatibility the better choice) as default.

But I do not fell that strongly about this