From 5f071fd2fa65992f80673f32754977422ef40796 Mon Sep 17 00:00:00 2001 From: Matthijs Hollemans Date: Thu, 28 Jan 2016 15:08:30 +0100 Subject: [PATCH] Add name to articles I'm doing this so that other contributors will follow the example and add their names to their explanations, to get credit for their work. --- Array2D/README.markdown | 2 ++ Boyer-Moore/README.markdown | 2 ++ Fixed Size Array/README.markdown | 2 ++ Insertion Sort/README.markdown | 2 ++ LICENSE.txt | 2 +- Queue/README.markdown | 2 ++ Selection Sort/README.markdown | 2 ++ Stack/README.markdown | 2 ++ Two-Sum Problem/README.markdown | 2 ++ 9 files changed, 17 insertions(+), 1 deletion(-) diff --git a/Array2D/README.markdown b/Array2D/README.markdown index 5e5ed6880..32cde4d67 100644 --- a/Array2D/README.markdown +++ b/Array2D/README.markdown @@ -103,3 +103,5 @@ let myCookie = cookies[column, row] Internally, `Array2D` uses a single one-dimensional array to store the data. The index of an object in that array is given by `(row x numberOfColumns) + column`. But as a user of `Array2D` you don't have to worry about that; you only have to think in terms of "column" and "row", and let `Array2D` figure out the details for you. That's the advantage of wrapping primitive types into a wrapper class or struct. And that's all there is to it. + +*Written by Matthijs Hollemans* diff --git a/Boyer-Moore/README.markdown b/Boyer-Moore/README.markdown index dc7b0a3ec..7050442e2 100644 --- a/Boyer-Moore/README.markdown +++ b/Boyer-Moore/README.markdown @@ -163,3 +163,5 @@ The closer a character is to the end of the pattern, the smaller the skip amount A caveat: If the search pattern consists of only a few characters, it's faster to do a brute-force search. There's a trade-off between the time it takes to build the skip table and doing brute-force for short patterns. Credits: This code is based on the article ["Faster String Searches" by Costas Menico](http://www.drdobbs.com/database/faster-string-searches/184408171) from Dr Dobb's magazine, July 1989 -- Yes, 1989! Sometimes it's useful to keep those old magazines around. + +*Written by Matthijs Hollemans* diff --git a/Fixed Size Array/README.markdown b/Fixed Size Array/README.markdown index 71d76bbe9..ec72852a8 100644 --- a/Fixed Size Array/README.markdown +++ b/Fixed Size Array/README.markdown @@ -137,3 +137,5 @@ var a = FixedSizeArray(maxSize: 10, defaultValue: 0) ``` Note that `removeAtIndex()` overwrites the last element with this `defaultValue` to clean up the "junk" object that gets left behind. Normally it wouldn't matter to leave that duplicate object in the array, but if it's a class or a struct it may have strong references to other objects and it's good boyscout practice to zero those out. + +*Written by Matthijs Hollemans* diff --git a/Insertion Sort/README.markdown b/Insertion Sort/README.markdown index 862fb04fe..ea39f5dad 100644 --- a/Insertion Sort/README.markdown +++ b/Insertion Sort/README.markdown @@ -231,3 +231,5 @@ I did a quick test comparing our `insertionSort()` with Swift's built-in `sort() ### See also See also [Wikipedia](https://en.wikipedia.org/wiki/Insertion_sort). + +*Written by Matthijs Hollemans* diff --git a/LICENSE.txt b/LICENSE.txt index 0bb69d008..51f54f145 100755 --- a/LICENSE.txt +++ b/LICENSE.txt @@ -1,4 +1,4 @@ -Copyright (c) 2016 Matthijs Hollemans +Copyright (c) 2016 Matthijs Hollemans and contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/Queue/README.markdown b/Queue/README.markdown index ae9f511da..ee31ff5a2 100644 --- a/Queue/README.markdown +++ b/Queue/README.markdown @@ -81,3 +81,5 @@ However, to dequeue we remove the element from the beginning of the array. This More efficient implementations would use a linked list, a circular buffer, or a heap. (I might add an example of this later.) Variations on this theme are [deque](../Deque/), a double-ended queue where you can enqueue and dequeue at both ends, and [priority queue](../Priority Queue/), a sorted queue where the "most important" item is always at the front. + +*Written by Matthijs Hollemans* diff --git a/Selection Sort/README.markdown b/Selection Sort/README.markdown index b074325e2..57b1d09f5 100644 --- a/Selection Sort/README.markdown +++ b/Selection Sort/README.markdown @@ -111,3 +111,5 @@ Selection sort is easy to understand but it performs quite badly, **O(n^2)**. It ### See also See also [Wikipedia](https://en.wikipedia.org/wiki/Selection_sort). + +*Written by Matthijs Hollemans* diff --git a/Stack/README.markdown b/Stack/README.markdown index 3870da88a..cac30a905 100644 --- a/Stack/README.markdown +++ b/Stack/README.markdown @@ -73,3 +73,5 @@ public struct Stack { Notice that a push puts the new element at the end of the array, not the beginning. Inserting at the beginning of an array is expensive, an **O(n)** operation, because it requires all existing array elements to be shifted in memory. Adding at the end is **O(1)**; it always takes the same amount of time, regardless of the size of the array. Fun fact about stacks: each time you call a function or a method, the return address is placed on a stack by the CPU. When the function ends, the CPU uses that return address to jump back to the caller. That's why if you call too many functions -- for example in a recursive function that never ends -- you get a so-called "stack overflow" as the CPU stack is out of space. + +*Written by Matthijs Hollemans* diff --git a/Two-Sum Problem/README.markdown b/Two-Sum Problem/README.markdown index 1d1bd91d9..ac64b763b 100644 --- a/Two-Sum Problem/README.markdown +++ b/Two-Sum Problem/README.markdown @@ -87,3 +87,5 @@ And finally, we have the answer: `12 + 21 = 33`. Yay! It's possible, of course, that there are no values for `a[i] + a[j]` that sum to `k`. In that case, eventually `i` and `j` will point at the same number. Then we can conclude that no answer exists and we return `nil`. I'm quite enamored by this little algorithm. It shows that with some basic preprocessing on the input data -- sorting it from low to high -- you can turn a tricky problem into a very simple and beautiful algorithm. + +*Written by Matthijs Hollemans*