Scribd
Upload
227 views4 pages

Comp2521 Lab03

This lab report summarizes an experiment to determine which sorting algorithms two programs use by measuring their execution time on different types of input data. The results show that Program A is likely insertion sort, while Program B uses a variant of merge sort based on its faster speed and similarity to the operating system's internal sort.

Uploaded by

Aditya Shrivastava
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
227 views4 pages

Comp2521 Lab03

This lab report summarizes an experiment to determine which sorting algorithms two programs use by measuring their execution time on different types of input data. The results show that Program A is likely insertion sort, while Program B uses a variant of merge sort based on its faster speed and similarity to the operating system's internal sort.

Uploaded by

Aditya Shrivastava
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

COMP2521 Sort Detective Lab Report

by Aditya Shrivastava (z5481870)

This lab aims to measure the performance of two sorting programs without access to the code
and determine which sorting algorithm each program uses.

Experimental Design
The measured execution time of the programs varied as the size and initial sortedness of the
input varied. The input types utilised include randomly ordered data, data sorted in ascending
order, data sorted in descending order, if stable then data with first and last elements reversed,
and data with repeated elements for stability assessment. These data sets will be executed and
the time of execution will be captured for comparison as the above algorithms have varying
runtime complexities for the varying datasets. For each dataset(except for repeated elements
data), a corresponding graph will be produced consisting of data size in incrementing order and
runtime for that sample size.

We used these test cases because, randomly ordered data helps evaluate under real-world
scenarios, as it provides a control for our overall comparison. Data sorted in ascending order is
useful to compare how the algorithms handle partially sorted input as certain algorithms have
optimisations for partially sorted data. Algorithms exposed to descending order behave
differently as they respond differently to negatively ordered input. Data with repeated elements
will assist in identifying stability in algorithms.

Stable sorting shall be identified through repeated data keys, this is because the relative order
of each string must be preserved once the sorting algorithm proceeds.

Because of the way timing works on Unix/Linux, it was necessary to repeat the same test
multiple times as system performance can be affected by various internal factors such as CPU
load, and other background processes running. Multiple tests avert these factors' impact as we
obtain more reliable information. Furthermore, repeating tests allows us to discard outliers in the
random data set tests.

Experimental Results
Following input data of type with repeated elements, shown below, we have the following
results.

For Program A, we observed that all elements with repeated keys had the relative order of their
corresponding strings preserved. This observation implies that algorithm A is a stable sorting
algorithm. Hence possible algorithms A can include insertion sort, merge sort and bubble sort.
For Program B, we observed that all elements with repeated keys had the relative order of their
corresponding strings preserved. This observation implies that algorithm B is a stable sorting
algorithm. Hence possible algorithms B can include insertion sort, merge sort and bubble sort.

Fig 1.

Fig 2.
Concluding Discussion

Since the algorithm is stable, It is worth noting here that the time complexity of random input
data for merge sort is of O(n*log(n)) whereas for insertion and bubble sort it is O(n^2).
Furthermore, for datasets of partial order in the form [n, 1, 2, 3, 4, 5, 6, …. , n - 1],insertion sort
has a time complexity of O(n), whereas bubble sort will have a time complexity of O(n^2). Thus
we would first assess with a random dataset, if it produces an n^2 looking trajectory, then we
shall assess using the partial order dataset.

Since the basis algorithm utilises merge sort, the time recorded for such may also be used to
distinguish from merge sort and bubble/insertion sort.

As shown in fig1, within randomly arranged data we see that B is much faster than A and, hence
must have a lower time complexity. Additionally, it is comparable to the internal sorting algorithm
which uses a variant of merge sort.

Since the time recorded for algorithm B is more closer to the sort function by the operating
system, we conclude B is the faster sort and is hence merge sort algorithm.

Furthermore, when tested with data that is sorted except for the ends swapped, there is not
much of a marginal difference in excecution speed for algorithm A, therefore it cannot be bubble
sort as for such data it exhibits time complexity of O(n) which is much faster than the rest.
Hence algorithm A is likely to be insertion sort as it depicts a more linear trajectory.

You might also like