Are asymptotic notations flawed?

Question

The best-case complexity of any algorithm is the minimum amount of time that the algorithm will take to accomplish its task. We know that the best case complexity of algorithms like merger sort, quick sort, etc is Ω(n log(n)), which defines the lower bound of these algorithms.

As we know that in asymptotic notations -

O(n) + O(n log(n)) = O(n log(n))

also,

Ω(n) + Ω(n log(n)) = Ω(n log(n))

So, if in these sorting algorithms, we first traverse the entire array in O(n) time to determine if the array is already sorted in ascending or descending order, then asymptotically their average case and worst case complexities would remain the same. But their best case complexity would now become Ω(n) .

Logically there is definitely a flaw in my way of understanding these asymptotic notations otherwise someone would definitely have had pointed this out when Asymptotic notations were being developed or becoming popular to measure sorting algorithms. Am I correct in assuming that this is a plausible flaw in asymptotic notations or am I missing some rule of Asymptotic notations?

Answer 1

There are certainly problems with using asymptotic complexity as a measure of speed. First and foremost, obviously constants do matter. 1000n will often be much larger than n log n , and certainly n^1000 is much larger than 2^n for any practical value of n . As it turns out, however, the asymptotic complexity is often a fairly good indicator of an algorithms actual speed.

The problem you raise is also correct, but I wouldn't consider it a problem. It is true that a simple isSorted() check at the start of quicksort reduces its best case complexity to Θ(n) , but it is very rare for people to care about best case performance. Indeed, many algorithms for common problems can be modified to be best case linear, but this is just not very useful.

Finally, note that this is not really a flaw in asymptotic notation specifically. Making a random guess and verifying whether the guess was correct (such as by guessing that an array is already sorted) often really does improve best case performance, while having very little effect on the average or worst case, regardless of the notation used.

Answer 2

First, you should distinguish in your mind between the case (best, worst, average, etc.) and the bound (upper, lower, O, Omega, Theta, etc.)

Let us focus on Bubble Sort, defined as follows:

if array == null or array.length < 2 then return
do
    swapped = false
    for i = 0 to array.length - 2
        if array[i] > array[i+1] then
            swap(array, i, i+1)
            swapped = true
until not swapped

The best case for this algorithm is a sorted array, in which case the lower (Omega), upper (O) and Theta bounds all agree the runtime is bound by a function of the form f(n) = an; that is, T(n) = O(n). The best case for Bubble Sort is linear.

The worst case for this algorithm is an array in reverse-sorted order. In this case, the runtime is bounded from above and below by a function like g(n) = bn^2; T(n) = O(n^2) in the worst case.

You aren't missing anything and it's perfectly ordinary for algorithms to have different worst-case and best-case runtime bounds. It's also perfectly possible that an algorithm may not optimize for the best case since the best case is typically not the one we are worried about anyway; yes, merge sort could first check to see if the array is sorted, but there are a relatively small number of those over the set of all possible arrays of length N.

Also, you may choose to talk about a lower bound on the worst case, or an upper bound on the best case. These things are not what we typically focus on - instead focusing on upper bound on the worst case, or possibly lower bound on the best case - but the case and the bound are totally separate things and can be combined arbitrarily.