Sorting and Searching Algorithms
Sorting and Searching Algorithms Documentation

Introduction

The implementation and evaluation of a collection of Sorting and Searching Algorithms.

Assignment Objective

The target collection those algorithms are operation on, is an 'Array Backed List'. This list shares (almost) the same interface (list.h) as the linked list from previous assignments but is implemented based on an array. Different sorting and searching algorithms are to be implemented using that list. A stopwatch shall be implemented that is used to measure the time a certain algorithm requires to sort or search. Eventually the measured times for defined number of list items and algorithms are compared.

Configuration

The capacity of the backing array of the list is defined in config.h as #define CAPACITY_INCREMENT. This value defines also the number of items for enlarging the backing array. This means, the array grows always in steps of CAPACITY_INCREMENT items.

Assignment

In this assignment various sorting and search algorithms shall be implemented in multiple steps.

Step 1:

Implemenation of an 'Array Backed List' by implementing files array_backed_list.h. This file implements list.h using an array as underlying collection instead of a linked list. In contrast to earlier assignments, the function list_append(…) was removed and list_swap(…) was added. The array shall have a certain capacity and need to be increased (with all consequences, such as of copying items) if another item is added to a 'full' list. As a benefit, random access to items is fast, which is required by (most) sorting and searching algorithms. For implementation details read and follow the instructions in file array_backed_list.c.

Step 2:

  • Implementation of the infrastructure for selecting and using sorting and searching algorithms as well as for measuring the time a certain algorithm takes for completing its operation.
  • Implemenation of bubble sort algorithm
  • Implementation of insertion algorithm
  • Implementation of sorting criteria that can be applied as paramter to the algorithm (function pointer)

Step 3:

Implemenation of the following sorting algorithms:

  • - TO BE DEFINED –

Working Instructions

The library 'allocator' is provided for memory allocation functionality that integrates with unit testing. Behind the facade, allocats memory dynamically similar to malloc. Allocated memory must be freed when it is not used anymore. The 'allocator' library must be used for memory alloction operations, otherwise unit tests will fail.

Step 1:

  1. Implement 'array_backed_list.c' against interface indirectly declared in 'list.h': Make the program and tests compile: Implement all functions in all relevant files declared in the headers EMTPY (return nothing, 0, false, ... as required).
    • All unit tests shall run but FAIL after this step
    • –COMMIT–
  2. Implement the empty functions one by one to make the unit tests.
    • Because most unit tests depends on list_obtain(…), list_release(…), list_is_valid(…), list_is_empty(…), list_insert(…), and list_get_size(…) it makes sense to implement those functions in one step.
    • The purpose of a function is specified as API documentation within the header files.
    • Obey comments in source files. Run the unit tests frequently and fix failures.
    • –COMMIT– after each implemented function.

Step 2:

  1. Based on 'array_backed_list' from step 1. If you don't own an implementation of that list (for good reasons), then:
    1. Implement the sorting algorithms based on a large, simple array (length: >= 2^16, see below).
    2. Comment the #define LIST_VARIANT in config.h to enable the functions using arrays and disable those for the list.
    3. Note Only one variant need to be implemented.
  2. Implement all functions defined by the file below empty to make the program compile. –COMMIT–
  3. stopwatch.[h|c] Implement the stopwatch. The stopwatch is required to measure the runtime of algorithms or execution steps. Details about the implementation of the stopwatch can be found in stopwatch.c. Run the unit tests targeting stop watch functionality and make them green. –COMMIT–
  4. sorting_criteria.[h|c]: Implement the sorting criteria function and the define the function pointer type for those functions. Run the unit tests targeting the sorting criteria functions and make them green. –COMMIT–
  5. bubble_sort.[h|c]: Implement the bubble sort algorithm. Run the unit tests targeting the bubble sort algorithm and make them green. –COMMIT–
  6. insertion_sort.[h|c]: Implement the insertion sort algorithm. Run the unit tests targeting the insertion sort algorithm and make them green. –COMMIT–
  7. sorting.[h|c]: Implement the support functions for the sorting application. These functions include initialization, printing (optional), and selection of the desired sorting algorithm. It also declares an enumeration of all supported sorting algorithms. Details regarding the implementation of those functions are mentioned in the top section of sorting.c. Run the unit tests targeting the sorting support function and make them green. –COMMIT–
  8. timed_sorting_main_driver.c: Implement the body of the measurement application. Organize the main application file as wanted. The application shall measure the time for sorting data of different size with all supported algorithms for the average, the best, and the worst case. In addition, it shall measure the time required for setting up and tearing down the data structure.

    For each supported sorting algorithm defined in sorting.h, starting with an item count of 1:

    1. Obtain the data structure (list or array) and initialize it randomly using the according function of sorting.h. Measure the time for this step as 'Init' time.
    2. Sort the data using the selected algorithm and measure the time for this step as 'Sort Avg' time.
    3. Sort the data using the selected algorithm again (in the same direction) and measure the time for this step as 'Sort Best' time.
    4. Sort the data using the selected algorithm in reverse direction and measure the time for this step as 'Sort Worst' time.
    5. Release the data structure (if applicable) and measure the time for this step as 'Release' time.
    6. Print the measured times as described below.
    7. Double the number of items to sort and repeat at step a) as long the item counter is less than 20k or 50k item (depending on your system).

    –COMMIT–

    The print outs as described above shall produce a table as shown below. The format pattern for the item count should be %7d and %10.1f for time values. Pipes | herein are not part of the format, they are just reqired for markdown. Such a data table can be examined further in a spreadsheet application such as MS Excel. Describe your observations, verify the runtime complexity based on your time measurements.

    Note:: You can take time measurements using different value for CAPACITY_INCREMENT. Only Init time should differ significantly.

Algorithm; Items; Sort_Avg; Sort_Best; Sort Worst; Init; Release
Bubble Sort; 1; 1.0; 1.0; 1.0; 5.0; 1.0
Bubble Sort; 2; 0.0; 0.0; 1.0; 3.0; 0.0
Bubble Sort; 4; 1.0; 0.0; 1.0; 3.0; 1.0
Bubble Sort; 8; 1.0; 0.0; 1.0; 3.0; 0.0
Bubble Sort; 16; 2.0; 0.0; 3.0; 3.0; 1.0
Bubble Sort; 32; 10.0; 1.0; 10.0; 17.0; 1.0
Bubble Sort; 64; 36.0; 1.0; 40.0; 4.0; 1.0
Bubble Sort; 128; 143.0; 2.0; 156.0; 5.0; 1.0
Bubble Sort; 256; 622.0; 3.0; 1676.0; 7.0; 1.0
Bubble Sort; 512; 2697.0; 7.0; 2855.0; 14.0; 1.0
Bubble Sort; 1024; 12267.0; 12.0; 11984.0; 23.0; 2.0
Bubble Sort; 2048; 43619.0; 25.0; 44301.0; 42.0; 2.0
Bubble Sort; 4096; 169480.0; 49.0; 181360.0; 78.0; 2.0
Bubble Sort; 8192; 667259.0; 98.0; 714083.0; 157.0; 1.0
Bubble Sort; 16384; 2683571.0; 350.0; 2837608.0; 408.0; 33.0
Bubble Sort; 32768; 10263822.0; 571.0; 11325744.0; 1879.0; 31.0
Insertion Sort; 1; 1.0; 1.0; 0.0; 218.0; 0.0
Insertion Sort; 2; 0.0; 0.0; 1.0; 2.0; 1.0
Insertion Sort; 4; 0.0; 0.0; 1.0; 2.0; 1.0
Insertion Sort; 8; 1.0; 0.0; 1.0; 2.0; 1.0
Insertion Sort; 16; 2.0; 1.0; 2.0; 2.0; 0.0
Insertion Sort; 32; 5.0; 1.0; 7.0; 2.0; 0.0
Insertion Sort; 64; 15.0; 2.0; 29.0; 2.0; 0.0
Insertion Sort; 128; 60.0; 3.0; 114.0; 4.0; 1.0
Insertion Sort; 256; 219.0; 5.0; 583.0; 6.0; 1.0
Insertion Sort; 512; 1010.0; 12.0; 2026.0; 11.0; 1.0
Insertion Sort; 1024; 4066.0; 28.0; 8800.0; 32.0; 2.0
Insertion Sort; 2048; 16718.0; 80.0; 33491.0; 35.0; 2.0
Insertion Sort; 4096; 64592.0; 205.0; 129536.0; 69.0; 2.0
Insertion Sort; 8192; 259646.0; 670.0; 524065.0; 142.0; 2.0
Insertion Sort; 16384; 1094843.0; 2327.0; 2075412.0; 360.0; 24.0
Insertion Sort; 32768; 4188706.0; 10525.0; 8367830.0; 1677.0; 34.0

Notes

  1. make cleantest: This new make target for clearing the console, building, and running unit test is available.
  2. Sometimes changes are not properly detected by incremental builds. If something very strange happens during compilation, try to run make clean followed by make to start a clean build. This approach is also recommended after everthing is done, because some compiler warning appears only in clean builds.