You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's useful to know how fast an algorithm is and how much space it needs. This allows you to pick the right algorithm for the job.
4
+
5
+
Big-O notation gives you a rough indication of the running time of an algorithm and the amount of memory it uses. When someone says, "This algorithm has worst-case running time of **O(n^2)** and uses **O(n)** space," they mean it's kinda slow but doesn't need lots of extra memory.
6
+
7
+
Figuring out the Big-O of an algorithm is usually done through mathematical analysis. We're skipping the math here, but it's useful to know what the different values mean, so here's a handy table. **n** refers to the number of data items that you're processing. For example, when sorting an array of 100 items, **n = 100**.
8
+
9
+
Big-O | Name | Description
10
+
------| ---- | -----------
11
+
**O(1)** | constant | **This is the best.** The algorithm always takes the same amount of time, regardless of how much data there is. Example: looking up an element of an array by its index.
12
+
**O(log n)** | logarithmic | **Pretty great.** These kinds of algorithms halve the amount of data with each iteration. If you have 100 items, it takes about 7 steps to find the answer. With 1,000 items, it takes 10 steps. And 1,000,000 items only take 20 steps. This is super fast even for large amounts of data. Example: binary search.
13
+
**O(n)** | linear | **Good performance.** If you have 100 items, this does 100 units of work. Doubling the number of items makes the algorithm take exactly twice as long (200 units of work). Example: sequential search.
14
+
**O(n log n)** | "linearithmic" | **Decent performance.** This is slightly worse than linear but not too bad. Example: the fastest general-purpose sorting algorithms.
15
+
**O(n^2)** | quadratic | **Kinda slow.** If you have 100 items, this does 100^2 = 10,000 units of work. Doubling the number of items makes it four times slower (because 2 squared equals 4). Example: algorithms using nested loops, such as insertion sort.
16
+
**O(n^3)** | cubic | **Poor performance.** If you have 100 items, this does 100^3 = 1,000,000 units of work. Doubling the input size makes it eight times slower. Example: matrix multiplication.
17
+
**O(2^n)** | exponential | **Very poor performance.** You want to avoid these kinds of algorithms, but sometimes you have no choice. Example: traveling salesperson problem.
18
+
**O(n!)** | factorial | **Intolerably slow.** It literally takes a million years to do anything.
19
+
20
+
Often you don't need math to figure out what the Big-O of an algorithm is but you can simply use your intuition. If your code uses a single loop that looks at all **n** elements of your input, the algorithm is **O(n)**. If the code has two nested loops, it is **O(n^2)**. Three nested loops gives **O(n^3)**, and so on.
21
+
22
+
Note that Big-O notation is an estimate and is only really useful for large values of **n**. For example, the worst-case running time for the [insertion sort](Insertion Sort/) algorithm is **O(n^2)**. In theory that is worse than the running time for [merge sort](Merge Sort/), which is **O(n log n)**. But for small amounts of data, insertion sort is actually faster, especially if the array is partially sorted already!
23
+
24
+
If you find this confusing, don't let this Big-O stuff bother you too much. It's mostly useful when comparing two algorithms to figure out which one is better. But in the end you still want to test in practice which one really is the best. And if the amount of data is relatively small, then even a slow algorithm will be fast enough for practical use.
Want to help out with the Swift Algorithm Club? Great!
4
+
5
+
## What sort of things can you contribute?
6
+
7
+
Take a look at the [list](README.markdown). Any algorithms or data structures that don't have a link yet are up for grabs.
8
+
9
+
New algorithms and data structures are always welcome (even if they aren't on the list).
10
+
11
+
We're always interested in improvements to existing implementations and better explanations. Suggestions for making the code more Swift-like or to make it fit better with the standard library.
12
+
13
+
Unit tests. Fixes for typos. No contribution is too small. :-)
14
+
15
+
## Please follow this process
16
+
17
+
To keep this a high quality repo, please follow this process when submitting your contribution:
18
+
19
+
1. Create a pull request to "claim" an algorithm or data structure. Just so multiple people don't work on the same thing.
20
+
2. Use this [style guide](https://github.com/raywenderlich/swift-style-guide) for writing code (more or less).
21
+
3. Write an explanation of how the algorithm works. Include **plenty of examples** for readers to follow along. Pictures are good. Take a look at [the explanation of quicksort](Quicksort/) to get an idea.
22
+
4. Include your name in the explanation, something like *Written by Your Name* at the end of the document. If you wrote it, you deserve the credit and fame.
23
+
5. Add a playground and/or unit tests.
24
+
25
+
Just so you know, I will probably edit your text and code for grammar etc, just to ensure a certain level of polish.
26
+
27
+
## Want to chat?
28
+
29
+
This isn't just a repo with a bunch of code... If you want to learn more about how an algorithm works or want to discuss better ways of solving problems, then open a [Github issue](https://github.com/hollance/swift-algorithm-club/issues) and we'll talk!
Copy file name to clipboardexpand all lines: README.markdown
+19-55
Original file line number
Diff line number
Diff line change
@@ -1,34 +1,22 @@
1
-
# Swift Algorithm Club
2
-
3
-
Welcome to the algorithm club!
1
+
# Welcome to the Swift Algorithm Club!
4
2
5
3
Here you'll find implementations of popular algorithms and data structures in everyone's favorite new language Swift, with detailed explanations of how they work.
6
4
7
-
If you're a computer science student who needs to learn this stuff for exams -- or if you're a self-taught programmer who wants to brush up on the theory behind your craft -- you've come to the right place.
5
+
If you're a computer science student who needs to learn this stuff for exams -- or if you're a self-taught programmer who wants to brush up on the theory behind your craft -- you've come to the right place!
8
6
9
-
The goal of this project is to explain how algorithms work. The focus is on clarity and readability of the code, not on making a reusable library that you can drop into your own projects. That said, most of the code should be ready for production use, but you may need to tweak it to fit into your own codebase.
7
+
The goal of this project is to **explain how algorithms work**. The focus is on clarity and readability of the code, not on making a reusable library that you can drop into your own projects. That said, most of the code should be ready for production use but you may need to tweak it to fit into your own codebase.
10
8
11
-
All code is compatible with **Xcode 7.2** and **Swift 2.1**.
9
+
All code is compatible with **Xcode 7.2** and **Swift 2.1**. We'll keep this updated with the latest version of Swift.
12
10
13
11
This is a work in progress. More algorithms will be added soon. :-)
14
12
15
-
**Suggestions and contributions are welcome!** Report an issue to leave feedback, or submit a pull request.
16
-
17
-
## How to contribute
18
-
19
-
To keep this a high quality repo, please follow this process when submitting your contribution:
13
+
## Important links
20
14
21
-
1. Create a pull request to "claim" an algorithm or data structure. Just so multiple people don't work on the same thing.
22
-
2. Use this [style guide](https://github.com/raywenderlich/swift-style-guide) for writing code (more or less).
23
-
3. Write an explanation of how the algorithm works. Include plenty of examples for readers to follow along.
24
-
4. Include your name in the explanation, something like *Written by Your Name* at the end of the document. If you wrote it, you deserve the credit and fame.
25
-
5. Add a playground and/or unit tests.
15
+
[Why learn algorithms?](Why Algorithms.markdown) Worried this isn't your cup of tea? Then read this.
26
16
27
-
Just so you know, I will probably edit your text and code for grammar etc, just to ensure a certain level of polish.
17
+
[Big-O notation](Big-O Notation.markdown). We often say things like, "This algorithm is **O(n)**." If you don't know what that means, read this first.
28
18
29
-
### What sort of things can you contribute?
30
-
31
-
New algorithms and data structures are always welcome (even if they aren't on the list). Improvements to existing implementations. Better explanations. Suggestions for making the code more Swift-like or to make it fit better with the standard library. Unit tests. Fixes for typos. No contribution is too small. :-)
19
+
[How to contribute](How to Contribute.markdown). Report an issue to leave feedback, or submit a pull request. **Suggestions and contributions are welcome!**
32
20
33
21
## Where to start?
34
22
@@ -39,7 +27,7 @@ If you're new to algorithms and data structures, here are a few good ones to sta
39
27
-[Insertion Sort](Insertion Sort/)
40
28
-[Binary Search](Binary Search/) and [Binary Search Tree](Binary Search Tree/)
41
29
-[Merge Sort](Merge Sort/)
42
-
-[Boyer-Moore](Boyer-Moore/) string search
30
+
-[Boyer-Moore string search](Boyer-Moore/)
43
31
44
32
## The algorithms
45
33
@@ -49,8 +37,8 @@ If you're new to algorithms and data structures, here are a few good ones to sta
49
37
-[Binary Search](Binary Search/). Quickly find elements in a sorted array.
50
38
-[Count Occurrences](Count Occurrences/). Count how often a value appears in an array.
51
39
-[Select Minimum / Maximum](Select Minimum Maximum). Find the minimum/maximum value in an array.
52
-
-[k-th Largest Element](Kth Largest Element/). Find the kth largest element in an array.
53
-
-[Selection Sampling](Selection Sampling/). Randomly choose a number of items from a collection.
40
+
-[k-th Largest Element](Kth Largest Element/). Find the *k*th largest element in an array, such as the median.
41
+
-[Selection Sampling](Selection Sampling/). Randomly choose a bunch of items from a collection.
54
42
- Union-Find
55
43
56
44
### String Search
@@ -87,6 +75,7 @@ Bad sorting algorithms (don't use these!):
87
75
88
76
### Compression
89
77
78
+
- Run-Length Encoding (RLE)
90
79
- Huffman Encoding
91
80
92
81
### Miscellaneous
@@ -111,12 +100,12 @@ First, there is the shape of your data and the kinds of operations that you'll n
111
100
112
101
Second, it matters what particular operations you'll be performing most, as certain data structures are optimized for certain actions. For example, if you often need to find the most important object in a queue, then a heap or priority queue is more optimal than a plain array.
113
102
114
-
Often just using the built-in `Array`, `Dictionary`, and `Set` types is sufficient, but sometimes you may want something more fancy...
103
+
Most of the time using just the built-in `Array`, `Dictionary`, and `Set` types is sufficient, but sometimes you may want something more fancy...
115
104
116
105
### Variations on arrays
117
106
118
107
-[Array2D](Array2D/). A two-dimensional array with fixed dimensions. Useful for board games.
119
-
-[Fixed Size Array](Fixed Size Array/). When you know beforehand how large your data will be, it might be more efficient to use an array with a fixed size.
108
+
-[Fixed Size Array](Fixed Size Array/). When you know beforehand how large your data will be, it might be more efficient to use an old-fashioned array with a fixed size.
120
109
-[Ordered Array](Ordered Array/). An array that is always sorted.
121
110
122
111
### Queues
@@ -146,6 +135,11 @@ Often just using the built-in `Array`, `Dictionary`, and `Set` types is sufficie
146
135
- Fibonacci Heap
147
136
- Trie
148
137
138
+
### Hashing
139
+
140
+
-[Hash Table](Hash Table/). Allows you to store and retrieve objects by a key. This is how the dictionary type is usually implemented.
141
+
- Hash Functions
142
+
149
143
### Sets
150
144
151
145
- Bit Set
@@ -154,11 +148,6 @@ Often just using the built-in `Array`, `Dictionary`, and `Set` types is sufficie
154
148
- Multiset
155
149
- Ordered Set
156
150
157
-
### Hashing
158
-
159
-
-[Hash Table](Hash Table/). Allows you to store and retrieve objects by a key. This is how the dictionary type is usually implemented.
160
-
- Hash Functions
161
-
162
151
### Graphs
163
152
164
153
- Graph
@@ -174,31 +163,6 @@ A lot of software developer interview questions consist of algorithmic puzzles.
174
163
175
164
-[Two-Sum Problem](Two-Sum Problem/)
176
165
177
-
## A note on Big-O notation
178
-
179
-
It's useful to know how fast an algorithm is and how much space it needs. This allows you to pick the right algorithm for the job.
180
-
181
-
Big-O notation gives you a rough indication of the running time of an algorithm and the amount of memory it uses. When someone says, "This algorithm has worst-case running time of **O(n^2)** and uses **O(n)** space," they mean it's kinda slow but doesn't need lots of extra memory.
182
-
183
-
Figuring out the Big-O of an algorithm is usually done through mathematical analysis. We're skipping the math here, but it's useful to know what the different values mean, so here's a handy table. **n** refers to the number of data items that you're processing. For example, when sorting an array of 100 items, **n = 100**.
184
-
185
-
Big-O | Name | Description
186
-
------| ---- | -----------
187
-
**O(1)** | constant | This is the best. The algorithm always takes the same amount of time, regardless of how much data there is. Example: looking up an element of an array by its index.
188
-
**O(log n)** | logarithmic | Pretty great. These kinds of algorithms halve the amount of data with each iteration. If you have 100 items, it takes about 7 steps to find the answer. With 1,000 items, it takes 10 steps. And 1,000,000 items only take 20 steps. This is super fast even for large amounts of data. Example: binary search.
189
-
**O(n)** | linear | Good performance. If you have 100 items, this does 100 units of work. Doubling the number of items to 200 makes the algorithm take twice as long (200 units of work). Example: sequential search.
190
-
**O(n log n)** | "linearithmic" | Decent performance. This is slightly worse than linear but not too bad. Example: the fastest sorting algorithms.
191
-
**O(n^2)** | quadratic | Kinda slow. If you have 100 items, this does 100^2 = 10,000 units of work. Doubling the number of items makes it four times slower (because 2 squared equals 4). Example: algorithms using nested loops, such as insertion sort.
192
-
**O(n^3)** | cubic | Poor performance. If you have 100 items, this does 100^3 = 1,000,000 units of work. Doubling the input size makes it eight times slower. Example: matrix multiplication.
193
-
**O(2^n)** | exponential | Very poor performance. You want to avoid these kinds of algorithms, but sometimes you have no choice. Example: traveling salesperson problem.
194
-
**O(n!)** | factorial | Intolerably slow. It literally takes a million years to do anything.
195
-
196
-
Often you don't need math to figure out what the Big-O of an algorithm is but you can simply use your intuition. If your code uses a single loop that looks at all **n** elements of your input, the algorithm is **O(n)**. If the code has two nested loops, it is **O(n^2)**. Three nested loops gives **O(n^3)**, and so on.
197
-
198
-
Note that Big-O notation is an estimate and is only really useful for large values of **n**. For example, the worst-case running time for the "insertion sort" algorithm is **O(n^2)**. In theory that is worse than the running time for "merge sort", which is **O(n log n)**. But for small amounts of data, insertion sort is actually faster, especially if the array is partially sorted already!
199
-
200
-
If you find this confusing, don't let this Big-O stuff bother you too much. It's mostly useful when comparing two algorithms to figure out which one is better. But in the end, you still want to test in practice which one really is the best. And if the amount of data is relatively small, then even a slow algorithm will be fast enough for practical use.
201
-
202
166
## Learn more!
203
167
204
168
For more information, check out these great books:
If you've been coding for while you may wonder what the point is of learning about algorithms and data structures, especially if you don't have a formal computer science or engineering background.
4
+
5
+
After all, how often do you actually have to use a linked list or write your own sort routine when you're making apps? The answer is: almost never.
6
+
7
+
#### **However...**
8
+
9
+
Knowing a little bit about the strategies used by algorithms to solve tricky problems gives you ideas for improvements you can make to your own code.
10
+
11
+
Knowing more data structures than just the standard array and dictionary gives you a bigger collection of tools you can use to build your own apps.
12
+
13
+
It will make you a better developer! (And better developers make more $$$.)
14
+
15
+
#### Algorithms lets you build software you couldn't otherwise build
16
+
17
+
There have been apps that I've been unable to create in the past because I got stuck on fundamental issues.
18
+
19
+
Often it was a matter of speed: I just couldn't make the program go fast enough. Thinking back on this now, I had chosen the wrong algorithms for these problems. If I had known more about the difference between **O(n)** and **O(n^2)**, then maybe I would have had better luck.
20
+
21
+
Naive brute-force solutions work fine for small amounts of data, but sometimes you need to deal with lots of data. And then you need smarter algorithms.
22
+
23
+
There were also times I wasn't able to solve my programming problems at all, not even slowly. I simply didn't know where to begin. Understanding a bit of algorithm theory gives you various tactics you can try.
24
+
25
+
#### Don't spend any time memorizing algorithms
26
+
27
+
That's not the point. Instead, try to understand how different algorithms approach different problems.
28
+
29
+
Learn about techniques such as divide-and-conquer, dynamic programming, greedy algorithms. See what makes one approach slow and another fast, and learn what the tradeoffs are.
30
+
31
+
The key thing here is to get insight in how we can make computers do things.
32
+
33
+
#### It's not as scary as it sounds
34
+
35
+
A lot of algorithm textbooks start with a bunch of math. Truth is, the math is useful but most of the time you won't need it. So don't let that scare you. If you can write code, you can also understand all these fancy algorithms and data structures.
0 commit comments