We will be exploring the implementation of various sorting algorithms. This continues our ongoing algorithm theme. And like other projects, it offers an opportunity to gain a deeper appreciation for differences in approaches.

There are many different sorting algorithms in existence, which are the result of different approaches to arrive at the intended solution: to arrange your data in accordance with the prescribed order.

For this project, our sorting order will be from greatest to least.

The sorting algorithms I'd like for your to implement are:

• insertion sort (https://en.wikipedia.org/wiki/Insertion_sort)
• selection sort (https://en.wikipedia.org/wiki/Selection_sort)
• shell sort (https://en.wikipedia.org/wiki/Shellsort)

Please do take note of the algorithmic complexity each algorithm offers, specifically:

• best case
• average case
• worst case

You are to use a linked list to accomplish your sorting algorithms, a simple implementation of which has been provided.

If you'd like to implementation additional list functionality (various list functions), that is also fine.

Linked lists and arrays are peers… they both can hold multiple objects of the same type. Both have advantages and disadvantages, depending on the sort of operations you are performing.

Here is a sample list implementation you are free to use (just place the code in your program):

1

struct number
{
    int            value;
    struct number *next;
};
typedef struct number Number;
 
Number *start;

Let's say we have the following values provided on the command-line: 67, 3, 57, 73, 1, 24, 37, 96, 13, 39, 26, 31, 4

The following code will build a list (beginning at the “start” pointer), and ending with a NULL value.

1

int     input  = 0;
Number *tmp    = NULL;
start          = NULL;
 
for (input = 1; input < argc; input++)
{
    if (start == NULL) // start being NULL indicates an EMPTY list
    {
        start  = (Number *) malloc(sizeof(Number)); // allocate new Number
        start -> value = atoi(argv[input]); // assign input into Number
        start -> next  = NULL;  // assign next value as NULL
        tmp    = start;         // tmp is pointing to the end of our list
    }
    else // non-NULL start means a populated list
    {
        tmp -> next    = (Number *) malloc(sizeof(Number)); // allocate new Number, attached at end of list
        tmp            = tmp -> next; // advance tmp pointer to newly allocated Number
        tmp -> value   = atoi(argv[input]); // assign input to new Number in list
        tmp -> next    = NULL; // set next to NULL (should be nothing after end of list)
    }
}

This is just a sample implementation; feel free to alter it as desired (doubly-linked? sure!)

Following will be a Bubble sort implementation (the one we did in class last week) utilizing the linked list implementation described above:

1

    int     frip    = 0;
    Number *outdex  = NULL;
    Number *index   = NULL;
 
    // display this from start to end
    tmp = start;
    fprintf(stdout, "BEFORE: ");
    while (tmp != NULL)
    {
        fprintf(stdout, "%2d ", tmp -> value);
        tmp = tmp -> next;
    }
    fprintf(stdout, "\n");
 
    outdex                              = start; // start outdex at start of list
    while (outdex                      != NULL) // keep looping until we're done with list
    {
        frip                            = 0; // our sort flag
        index                           = start; // start index at start of list
        while (index  -> next          != NULL) // loop through the list
        {
            if (index -> value         <  index -> next -> value)
            {
                index -> value          = index -> value ^ index -> next -> value;
                index -> next -> value  = index -> value ^ index -> next -> value;
                index -> value          = index -> value ^ index -> next -> value;
                frip                    = 1;
            }
            index                       = index -> next;
        }
 
        if (frip                       == 0)
            break;
 
        outdex                          = outdex -> next;
    }
 
    // display this from start to end
    tmp = start;
    fprintf(stdout, "AFTER:  ");
    while (tmp != NULL)
    {
        fprintf(stdout, "%2d ", tmp -> value);
        tmp = tmp -> next;
    }
    fprintf(stdout, "\n");
 
    return(0);

In this case we didn't actually manipulate Number pointers. That is okay for this project; if you would like to, then by all means, feel free :)

NOTE: This code is available as a fully working program in the project grabit, in a file called bubble.c

Your program's output should be as follows:

lab46:~/src/discrete/smh0$ ./bubble 67 3 57 37 1 24 37 96 13 39 26 31 4
BEFORE: 67  3 57 37  1 24 37 96 13 39 26 31  4
AFTER:  96 67 57 39 37 37 31 26 24 13  4  3  1
lab46:~/src/discrete/smh0$ 

Your task is to write 3 separate, standalone programs that each has linked-list implementations of the identified sorting algorithms.

Each will accept all their input values via the command-line (as numeric arguments), should load into a list, and then proceed with processing in accordance with the identified sorting algorithm.

Please display the list both BEFORE and AFTER the selected sorting algorithm takes place (and remember sorting order!). Please format your BEFORE/AFTER lines in accordance with output examples given. This will aid in verification.

If you'd like to also include more intermediate sorting steps (for display/debugging purposes), feel free to do so, but please disable them before your final project submission. Your programs should ONLY output the full BEFORE/AFTER lines.

It shouldn't matter if we use an array or a linked list- but since most examples you'll find on the internet use arrays, this is a means of ensuring you really understand what is going on (ie reduce the temptation to just mindlessly copy and not understand). It shouldn't matter if you are in Data Structures now, have taken it before, or have not taken it… it is merely a connection of values in memory (JUST like an array).

To submit this program to me using the submit tool, run the following command at your lab46 prompt:

lab46:~/src/discrete/smh0$ make submit
...
SUCCESSFULLY SUBMITTED

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

To be successful in this project, the following criteria must be met:

• Project must be submit on time, by the posted deadline.
  • Early submissions will earn 1 bonus point per full day in advance of the deadline.
    • Bonus eligibility requires an honest attempt at performing the project (no blank efforts accepted)
  • Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline.
    • To clarify: if a project is due on Wednesday (before its end), it would then be 25% off on Thursday, 50% off on Friday, 75% off on Saturday, and worth 0% once it becomes Sunday.
    • Certain projects may not have a late grace period, and the due date is the absolute end of things.
• all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).
• Output generated must conform to any provided requirements and specifications (be it in syntax or sample output)
  • output obviously must also be correct based on input.
• Processing must be correct based on input given and output requested
• Specification details are NOT to be altered. This project will be evaluated according to the specifications laid out in this document.
• Following are some common evaluation criteria; these may be included, enhanced, and supplemented.
• Code must compile cleanly.
  • Each source file must compile cleanly (worth 3 total points):
    • 3/3: no compiler warnings, notes or errors.
    • 2/3: one of warning or note present during compile
    • 1/3: two of warning or note present during compile
    • 0/3: compiler errors present (code doesn't compile)
• Code must be nicely and consistently indented (you may use the indent tool)
  • You are free to use your own coding style, but you must be consistent
  • Avoid unnecessary blank lines (some are good for readability, but do not go overboard- double-spacing your code will get points deducted).
  • Indentation will be rated on the following scale (worth 3 total points):
    • 3/3: Aesthetically pleasing, pristine indentation, easy to read, organized
    • 2/3: Mostly consistent indentation, but some distractions (superfluous or lacking blank lines, or some sort of “busy” ness to the code)
    • 1/3: Some indentation issues, difficult to read
    • 0/3: Lack of consistent indentation (didn't appear to try)
• Code must be commented
  • Commenting will be rated on the following scale (worth 3 total points):
    • 3/3: Aesthetically pleasing (comments aligned or generally not distracting), easy to read, organized
    • 2/3: Mostly consistent, some distractions or gaps in comments (not explaining important things)
    • 1/3: Light commenting effort, not much time or energy appears to have been put in.
    • 0/3: No original comments
    • should I deserve nice things, my terminal is usually 90 characters wide. So if you'd like to format your code not to exceed 90 character wide terminals (and avoid line wrapping comments), at least as reasonably as possible, those are two sure-fire ways of making a good impression on me with respect to code presentation and comments.
  • Sufficient comments explaining the point of provided logic MUST be present
• Code must be appropriately modified
  • Appropriate modifications will be rated on the following scale (worth 3 total points):
    • 3/3: Complete attention to detail, original-looking implementation
    • 2/3: Lacking some details (like variable initializations), but otherwise complete (still conforms, or conforms mostly to specifications)
    • 1/3: Incomplete implementation (typically lacking some obvious details/does not conform to specifications)
    • 0/3: Incomplete implementation to the point of non-functionality (or was not started at all)
  • Implementation must be accurate with respect to the spirit/purpose of the project (if the focus is on exploring a certain algorithm to produce results, but you avoid the algorithm yet still produce the same results– that's what I'm talking about here).. worth 3 total points:
    • 3/3: Implementation is in line with spirit of project
    • 2/3: Some avoidance/shortcuts taken (note this does not mean optimization– you can optimize all you want, so long as it doesn't violate the spirit of the project).
    • 1/3: Generally avoiding the spirit of the project (new, different things, resorting to old and familiar, despite it being against the directions)
    • 0/3: entirely avoiding.
  • Error checking must be adequately and appropriately performed, according to the following scale (worth 3 total points):
    • 3/3: Full and proper error checking performed for all reasonable cases, including queries for external resources and data.
    • 2/3: Enough error checking performed to pass basic project requirements and work for most operational cases.
    • 1/3: Minimal error checking, code is fragile (code may not work in full accordance with project requirements)
    • 0/3: No error checking (code likely does not work in accordance with project requirements)
• Track/version the source code in a repository
• Submit a copy of your source code to me using the submit tool (make submit will do this) by the deadline.