should i change something?

@crabman448 checking it out now

Thank you for your comments! 👍
I will fix it as soon as possible :)

Will improve it in a couple days. Thank you again! : )

Thanks a lot again) But I'm not agree with concept, that it would be better to use directed graph. Because, about 2 months ago I was looking for algorithm, that will be possible to use in not directed graph. And I thought, that Dijkstra won't satisfy my requirements, because explanations mostly used directed graphs, but I needed to go in both directions on every edge.
Maybe it would be better to add both directed and not directed graph explanations?

Interesting. Dijkstra's algorithm should be functionally identical for both undirected and directed graphs. I can't picture why you would want to go in both directions for every edge. You'd never want to travel back and forth since that only increases your total distance.

Could you explain why you needed to go in both directions using Dijkstra's?

In my app I have a graph, that is not directed at all. You can go in both directions on every edge. And when I was searching for suitable algorithm, I've seen some explanations with directed graph and I was like: "That won't work in my case, because I have not directed weighted graph". But it would, because it works for not directed graphs to.

In a park, for example, people can go in both directions on footpaths.

Let's take this step by step. If you want to find the shortest path between 2 vertexes in a graph, would you ever want to travel down a single undirected edge more than once?

Probably I won't. But I don't know whether i'll travel up or down an edge. So it doesn't make sense to create directed graph with both directions on every edge.

Can you elaborate on that? One of the most common ways to represent an undirected graph is to use a directed graph where every edge is paired with another edge going in the opposite direction.

But why? It is extra work, isn't it? :)

If I have not directed graph, why should I make it directed?

@crabman448 I took a look at your implementation, here's what I mean:

func setupConnections() {
 // ...
 let neighbor1 = (neighborVertex, randomWeight)
 let neighbor2 = (vertex, randomWeight)
 vertex.neighbors.append(neighbor1)
 neighborVertex.neighbors.append(neighbor2)
}

neighbor1 and neighbor2 are your directed edges. They represent the destination and the weight of the edge. Your undirected graph is built by using a pair of directed edges. Every connection you make is done by adding a pair of edges.

You're right about it being extra work - hence I suggest we base the explanation based on a directed graph.

To create a directed graph, all you need to do is remove one of the pairs:

func setupConnections() {
 // ...
 let neighbor1 = (neighborVertex, randomWeight)
 vertex.neighbors.append(neighbor1)
}

Now your graph is a directed graph, with exactly half as many edges than your previous undirected graph. I recommend reading our tutorial on adjacency lists for more info.

Hmm, got you)
"In an undirected graph, you can treat it as a directed graph that goes both ways."
So, when all graph's edges are bidirectional, then it is still directed graph? And there is no other way to achieve such behaviour?

Yes

An undirected graph is a directed graph where every edge has another edge going in the opposite direction

• All undirected graphs can be viewed as a directed graph.
• A directed graph is undirected if and only if every edge is paired with an edge going in the opposite direction

Things have become clearer)) Thank you again. I will mention this statement in the beginning of the readme.

I'm currently busy with my graduating project in the university. I'll fix description as soon as I will have enough time)

Awesome work. I can see both of you are diligently making progress over many days. Looking forward to see this completed.

I'm back now :)
Hope, that I will finish in a couple of days.

I've added some general concepts about graphs, but I would like to use example with shops and choosing the closest one of them, because it correlates better with Dijkstra's algorithm: Shortest paths from source vertex to all others.
I'll check grammar, punctuation and spelling mistakes soon)

@kelvinlauKL I've checked grammar etc and hope it is ready for merge now :)

Nice. I just did a quick read and it's shaping up very nicely. Great improvements!

I'll do a more thorough review in the next few days.

Woot, I had a chance to read over it. It's much nicer than before. This is ready for a merge.

I think there's still lots of room for improvement in areas like readability, so if you have time, consider spending more time improving the readme files. Thanks @crabman448!