summaryrefslogtreecommitdiffhomepage
path: root/asymptotic-notation.html.markdown
diff options
context:
space:
mode:
authorGraham Mueller <graham.mueller315@gmail.com>2015-02-01 11:49:19 -0600
committerGraham Mueller <graham.mueller315@gmail.com>2015-02-01 11:49:19 -0600
commita5283ebff1ab87c37efc5e83867070aeea743427 (patch)
treef9f5fb2fc4d8f70c3cc69d96afbfe2336e8cbc7a /asymptotic-notation.html.markdown
parent287133fc49b51df19c2da24b49266085a19e8268 (diff)
Update asymptotic-notation.html.markdown
Fixing some grammar and incorrect usage of it's. Replacing description of why not to use best case. Changing some formatting to hopefully make it read a little easier.
Diffstat (limited to 'asymptotic-notation.html.markdown')
-rw-r--r--asymptotic-notation.html.markdown46
1 files changed, 19 insertions, 27 deletions
diff --git a/asymptotic-notation.html.markdown b/asymptotic-notation.html.markdown
index f09d4d27..50fa6f4f 100644
--- a/asymptotic-notation.html.markdown
+++ b/asymptotic-notation.html.markdown
@@ -8,10 +8,10 @@ contributors:
## What are they?
-Asymptotic Notations are languages that allows us to analyze an algorithm's running time by
+Asymptotic Notations are languages that allow us to analyze an algorithm's running time by
identifying its behavior as the input size for the algorithm increases. This is also known as
an algorithm's growth rate. Does the algorithm suddenly become incredibly slow when the input
-size grows? Does it mostly maintain it's quick run time as the input size increases?
+size grows? Does it mostly maintain its quick run time as the input size increases?
Asymptotic Notation gives us the ability to answer these questions.
## Are there alternatives to answering these questions?
@@ -35,12 +35,8 @@ runtime, X axis is the input size, and plot points are the resultants of the amo
for a given input size.
You can label a function, or algorithm, with an Asymptotic Notation in many different ways.
-Some examples are, you can describe an algorithm by it's best case, worse case, or equivalent case.
-The most common is to analyze an algorithm by it's worst case. This is because if you determine an
-algorithm's run time or time complexity, by it's best case, what if it's best case is only obtained
-given at a low, unrealistic, input size? It is equivalent to having a 5 meter sprinting race to find
-the fastest sprinter on earth. Or testing the 40 to 50MPH time of a car to determine the fastest car
-in the world. The measurement loses meaning because it doesn't represent the problem well.
+Some examples are, you can describe an algorithm by its best case, worse case, or equivalent case.
+The most common is to analyze an algorithm by its worst case. You typically don't evaluate by best case because those conditions aren't what you're planning for. A very good example of this is sorting algorithms; specifically, adding elements to a tree structure. Best case for most algorithms could be as low as a single operation. However, in most cases, the element you're adding will need to be sorted appropriately through the tree, which could mean examining an entire branch. This is the worst case, and this is what we plan for.
### Types of functions, limits, and simplification
```
@@ -51,15 +47,11 @@ Polynomial Function - an^z + . . . + an^2 + a*n^1 + a*n^0, where z is some const
Exponential Function - a^n, where a is some constant
```
-These are some basic function growth classifications used in various notations. The list starts at the least
-fast growing function (logarithmic) and goes on to the fastest growing (exponential). Notice that as 'n', or the input,
-increases in each of those functions, the result clearly increases much quicker in quadratic, polynomial, and
-exponential, compared to logarithmic and linear.
+These are some basic function growth classifications used in various notations. The list starts at the slowest growing function (logarithmic, fastest execution time) and goes on to the fastest growing (exponential, slowest execution time). Notice that as 'n', or the input, increases in each of those functions, the result clearly increases much quicker in quadratic, polynomial, and exponential, compared to logarithmic and linear.
-One extremely important note is that for the notations about to be discussed you should do your best to use simplest terms.
-This means to disregard constants, and lower order terms, because as the input size (or n in our f(n)
+One extremely important note is that for the notations about to be discussed you should do your best to use simplest terms. This means to disregard constants, and lower order terms, because as the input size (or n in our f(n)
example) increases to infinity (mathematical limits), the lower order terms and constants are of little
-to no importance. That being said, if you have constants that are 2^9001, or some other ridiculous
+to no importance. That being said, if you have constants that are 2^9001, or some other ridiculous,
unimaginable amount, realize that simplifying will skew your notation accuracy.
Since we want simplest form, lets modify our table a bit...
@@ -73,9 +65,9 @@ Exponential - a^n, where a is some constant
### Big-Oh
Big-Oh, commonly written as O, is an Asymptotic Notation for the worst case, or ceiling of growth
-for a given function. Say f(n) is your algorithm runtime, and g(n) is an arbitrary time complexity
-you are trying to relate to your algorithm. f(n) is O(g(n)), if for any real constant c (c>0),
-f(n) <= c g(n) for every input size n (n>0).
+for a given function. Say `f(n)` is your algorithm runtime, and `g(n)` is an arbitrary time complexity
+you are trying to relate to your algorithm. `f(n)` is O(g(n)), if for any real constant c (c > 0),
+`f(n)` <= `c g(n)` for every input size n (n > 0).
*Example 1*
```
@@ -83,9 +75,9 @@ f(n) = 3log n + 100
g(n) = log n
```
-is f(n) O(g(n))?
-is 3 log n + 100 O(log n)?
-Let's look to the definition of Big-Oh.
+Is `f(n)` O(g(n))?
+Is `3 log n + 100` O(log n)?
+Let's look to the definition of Big-Oh.
```
3log n + 100 <= c * log n
```
@@ -93,7 +85,7 @@ Is there some constant c that satisfies this for all n?
```
3log n + 100 <= 150 * log n, n > 2 (undefined at n = 1)
```
-Yes! The definition of Big-Oh has been met therefore f(n) is O(g(n)).
+Yes! The definition of Big-Oh has been met therefore `f(n)` is O(g(n)).
*Example 2*
```
@@ -101,20 +93,20 @@ f(n) = 3*n^2
g(n) = n
```
-is f(n) O(g(n))?
-is 3 * n^2 O(n)?
+Is `f(n)` O(g(n))?
+Is `3 * n^2` O(n)?
Let's look at the definition of Big-Oh.
```
3 * n^2 <= c * n
```
Is there some constant c that satisfies this for all n?
-No there isn't, f(n) is NOT O(g(n)).
+No, there isn't. `f(n)` is NOT O(g(n)).
### Big-Omega
Big-Omega, commonly written as Ω, is an Asymptotic Notation for the best case, or a floor growth rate
for a given function.
-f(n) is Ω(g(n)), if for any real constant c (c>0), f(n) is >= c g(n) for every input size n (n>0).
+`f(n)` is Ω(g(n)), if for any real constant c (c > 0), `f(n)` is >= `c g(n)` for every input size n (n > 0).
Feel free to head over to additional resources for examples on this. Big-Oh is the primary notation used
for general algorithm time complexity.
@@ -122,7 +114,7 @@ for general algorithm time complexity.
### Ending Notes
It's hard to keep this kind of topic short, and you should definitely go through the books and online
resources listed. They go into much greater depth with definitions and examples.
-More where x='Algorithms & Data Structures' is on it's way; we'll have a doc up on analyzing actual
+More where x='Algorithms & Data Structures' is on its way; we'll have a doc up on analyzing actual
code examples soon.
## Books