LinkedList optimizations: -added counter variable -added overflow/underflow exceptions -moved counter to read-only property -moved code to function nodeAtIndex function -changed variables to optionals for readability -removed overcompilcated code blocks -removed Enumerable constraint for T -removed print

LLNode optimizations: -added default init and parametrized init to LLNode

Tests modifications: -added try! code block to bypass exception handling

I was trying to use the Trie code and the following had an error.

let searchKey: String = keyword.substringToIndex(current.level + 1) can't convert Int to Index

Fix it by casting to NSString let searchKey: String = (keyword as NSString).substringToIndex(current.level + 1)

Also keyword.length becomes keyword.characters.count

We currently have a merge sort algorithm in our repo, but I feel this could be refactored into a more efficient / simplified model. The resulting code would be published in essay format.

The main advantage of hash table is quick access to elemets:

Time complexity for hash tables (from wiki):

| Type | Average | Worst case | | --- | --- | --- | | Space | O(n) | O(n) | | Search | O(1) | O(n) | | Insert | O(1) | O(n) | | Delete | O(1) | O(n) |

Since your hash table implemented as loop in array - the average complexity of search is O(n), not O(1), that not fit this time complexity requirements of hash tables. For correct implementation of this structure hash table should be implemented as Dictionary

I think there is a bug in the implementation of Queue.deQueue() . Consider the following code:

var w = Queue<Int>()
println(w.count) // prints "0" as expected
w.enQueue(1)
println(w.count) // prints "1" - as expected
w.deQueue()
println(w.count) // should print "0", but instead, you get a fatal error

In xCode 6.3.1, this code in a playground gives the following fatal error: fatal error: unexpectedly found nil while unwrapping an Optional value Playground execution failed: Execution was interrupted, reason: EXC_BAD_INSTRUCTION

This is due to the fact that deQueue() at line 102 sets top to nil when there is no next item in the queue. count then blows up when it tries to access top.key which is an implicitly unwrapped optional. A fix would be to instead set top to QNode<T>() on 102.

Sorting is one of most popular essays at www.waynewbishop.com. As part of this I would like refactor the article to include the newly added examples of Quick Sort and Merge Sort. The essay illustrations should also be redone or removed.

www.waynewbishop.com/swift/sorting-algorithms

Problem

When searching for a key within a non-complete array (e.g. [0,4,7,9,13,16,34] as opposed to [0,1,2,3,4,5,6,7]) the binarySearch() function returns an initial correct print statement followed by a false positive.

Run:

sorting.binarySearch([0,4,7,9,13,16,34], key: 8)

Result:

   search value 8 not found..
   search value 8 found..

Solution implemented this PR

• Updated binarySearch(_:) to be testable (now returns true or false depending on whether the key was found in the sequence)
• Updated the test to test all possible values of a given array

LinkedList optimizations: -added counter variable -added overflow/underflow exceptions -moved counter to read-only property -moved code to function nodeAtIndex function -changed variables to optionals for readability -removed overcompilcated code blocks -removed Enumerable constraint for T -removed print

LLNode optimizations: -added default init and parametrized init to LLNode

Tests modifications: -added try! code block to bypass exception handling

In Swift, parentheses in loops / control structures are optional. They often times make readability easier, but in some cases can also overly complicate the code. It is up to you whether you want to use them or not, but there are a couple of places in this project in which I feel they could be removed. Here is an example:

In Source/Factories/LinkedList.swift:

//the number of items
    var count: Int {

            if (head.key == nil) {
                return 0
            }

            else  {

                var current: LLNode = head
                var x: Int = 1


                //cycle through the list of items
                while ((current.next) != nil) {
                    current = current.next!
                    x++
                }

                return x

            }
    }

I think that we could change the code, for example in the if statement, to be:

var count: Int {

            if head.key == nil {
                return 0
            }

and in the while loop:

//cycle through the list of items
                while current.next != nil {
                    current = current.next!
                    x++
                }

Again, up to you, the author, but I think it could help Swift learners looking at this code to recognize some of the readability features of Swift versus Objective-C.

Hi Richard;

Just making some notes. When refactoring the merge sort it looks like we can also remove this extension as well.

extension Int {

    //iterates the closure body a specified number of times
    func times(closure:(Int)->Void) {
        for i in 0...self {
            closure(i)
        }
    }

}

I've fixed implementation of QuickSort. New implementation ensures O(n log n) complexity for case when array contains duplicates. Old realisation provided quadratic time for such cases. I've added tests to check QuickSort with different cases - with duplicates, with different array sized, already sorted array.

…nt of 1

This crash can be reproduced by creating a new LinkedList, adding a value, and then immediately removing it. The crash occurs because head.next is nil.

Additionally, I moved the index == 0 check before the initialization of current, as it doesn't need to use it.

I can change the ternary operator to an if-statement if you think it's more readable.