Graphs Pattern

[jbgriesner]

An idiomatic way to implement graphs in Rust.

[FraGag]

If a node can have at most one parent, then the data structure is a tree, not a graph. Nodes in a graph can have more than one parent.

[lambda-fairy]

It looks more like a forest, since this code allows for multiple roots 😉

[nrc]

This is a way to have a graph in Rust, I'm not sure if its the best way. It's also possible to use Rc and RefCell with some kind of cycle tracking/detection, or unsafe code in numerous ways.

[jbgriesner]

I made a distinction.
I will code different ways to have graph.

[lambda-fairy]

Found this while going through old PRs.

In my view, the intention of this patterns repo is to document situations where there is usually one "best" solution. So an overview of many different graph implementations, while valuable, would not belong here.

I will close this PR. Thanks!

[simonsan]

In my view, the intention of this patterns repo is to document situations where there is usually one "best" solution. So an overview of many different graph implementations, while valuable, would not belong here.

I will close this PR. Thanks!

Imho a best solution is developed over time, I think it could be valuable, as this content doesn't exist in the repository already, to state explicitly that it's not sure to be the best solution but that PRs are welcome to improve the examples or encourage discussion on it to come to a better solution, so I'm reopening it for further inspection.

[simonsan]

But yeah, I know what lambda-fairy wanted to state, it's hard to tell this is a good solution or this not. My guess with the book would probably be a subchapter with graphs and then give some examples

or

probably better to explain the internal graph data structures as a pattern, something like that:
https://doc.rust-lang.org/1.1.0/src/rustc_data_structures/graph/mod.rs.html#11-403

and give input on how you would do that on not give some custom implementation. But maybe some recommended crates with already implemented data structures to use, to not reinvent the wheel.

Hmm, thoughts?

[fade2black]

I think Graph data structure, on its own, is too wide topic to cover in a couple of pages. As a rule, complexity of algorithms on graphs directly depends their representation. What kind of representation we will choose depends on our use case. Factors to take into account:

• type of graphs: complete graph, trees, directed, undirected, etc.
• compute intensive: speed/complexity of algorithms is important, for example depending on representation DFS algorithm may work in O(n^2) or O(n + m).
• scarce memory (embedded systems for example)
• what kind of algorithm we implement: parallel, distributed...
• Is graph dynamic?: we constantly add/remove vertices/edges...
• amortised cost: for example amortised costs are given in documentations for some data structures.

Let me give a simple example. Say, I know my graph changes (new edges or vertex) once a day, but the graph is almost complete and in my algorithms I traverse neighbours of a single vertex not too often. I'd probably use adjacency matrix.

Or another example. If we know that our graph has too few edges and we do extensive DFS then matrix is a bad choice since it would have O(n^2) complexity, while using adj list we could reduce it to linear time O(n) if say m is liner in n.

[simonsan]

I think as well, that it should be a complete chapter of different graph structures, would you agree?

[fade2black]

@simonsan I agree. We could categorise into use cases or representations, or anything else what people think. But not everything in a single page. Of course the Rust way should be put on the first place.

[simonsan]

@simonsan I agree. We could categorise into use cases or representations, or anything else what people think. But not everything in a single page. Of course the Rust way should be put on the first place.

I opened an issue for discussions, it's easier going forward I guess

[pickfire]

This is too wide and there are few patterns to solve this. But there are also many cases of graph, I think we may need a category rather than writing it like this. For example:

• self-referencing graphs (there are even multiple ways to solve this IIRC and this is a common pitfall I think)
• struct of array vs array of structure
• allocate memory somewhere else and keep reference/index

[simonsan]

This is too wide and there are few patterns to solve this. But there are also many cases of graph, I think we may need a category rather than writing it like this. For example:

* self-referencing graphs (there are even multiple ways to solve this IIRC and this is a common pitfall I think)

* struct of array vs array of structure

* allocate memory somewhere else and keep reference/index

Let's use issue #202 to discuss it, I'll mark this as zombie for the future and close it for now.