iskm/learnxinyminutes-docs
1
0
Fork 0
mirror of https://github.com/adambard/learnxinyminutes-docs.git synced 2024-12-23 17:41:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Some grammar, vocabulary, stylistic changes

Browse Source
This commit is contained in:
Rinat M 2020-02-27 14:58:17 -05:00 committed by GitHub
parent 9c6084c33e
commit 390354b6f2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 31 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
asymptotic-notation.html.markdown
View File

@ -31,24 +31,24 @@ specifications, processing power, etc.
## Types of Asymptotic Notation ## Types of Asymptotic Notation
In the first section of this doc we described how an Asymptotic Notation In the first section of this doc, we described how an Asymptotic Notation
identifies the behavior of an algorithm as the input size changes. Let us identifies the behavior of an algorithm as the input size changes. Let us
imagine an algorithm as a function f, n as the input size, and f(n) being imagine an algorithm as a function f, n as the input size, and f(n) being
the running time. So for a given algorithm f, with input size n you get the running time. So for a given algorithm f, with input size n you get
some resultant run time f(n). This results in a graph where the Y axis is the some resultant run time f(n). This results in a graph where the Y-axis is
runtime, X axis is the input size, and plot points are the resultants of the the runtime, the X-axis is the input size, and plot points are the resultants
amount of time for a given input size. of the amount of time for a given input size.
You can label a function, or algorithm, with an Asymptotic Notation in many You can label a function, or algorithm, with an Asymptotic Notation in many
different ways. Some examples are, you can describe an algorithm by its best different ways. Some examples are, you can describe an algorithm by its best
case, worse case, or equivalent case. The most common is to analyze an case, worst case, or average case. The most common is to analyze an algorithm
algorithm by its worst case. You typically don't evaluate by best case because by its worst case. You typically don’t evaluate by best case because those
those conditions aren't what you're planning for. A very good example of this conditions aren’t what you’re planning for. An excellent example of this is
is sorting algorithms; specifically, adding elements to a tree structure. Best sorting algorithms; particularly, adding elements to a tree structure. The
case for most algorithms could be as low as a single operation. However, in best case for most algorithms could be as low as a single operation. However,
most cases, the element you're adding will need to be sorted appropriately in most cases, the element you’re adding needs to be sorted appropriately
through the tree, which could mean examining an entire branch. This is the through the tree, which could mean examining an entire branch. This is
worst case, and this is what we plan for. the worst case, and this is what we plan for.
### Types of functions, limits, and simplification ### Types of functions, limits, and simplification
@ -61,20 +61,22 @@ constant
Exponential Function - a^n, where a is some constant Exponential Function - a^n, where a is some constant
``` ```
These are some basic function growth classifications used in various These are some fundamental function growth classifications used in
notations. The list starts at the slowest growing function (logarithmic, various notations. The list starts at the slowest growing function
fastest execution time) and goes on to the fastest growing (exponential, (logarithmic, fastest execution time) and goes on to the fastest
slowest execution time). Notice that as 'n', or the input, increases in each growing (exponential, slowest execution time). Notice that as ‘n’
of those functions, the result clearly increases much quicker in quadratic, or the input, increases in each of those functions, the result
polynomial, and exponential, compared to logarithmic and linear. 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 It is worth noting that for the notations about to be discussed,
you should do your best to use simplest terms. This means to disregard you should do your best to use the simplest terms. This means to
constants, and lower order terms, because as the input size (or n in our f(n) disregard constants, and lower order terms, because as the input
example) increases to infinity (mathematical limits), the lower order terms size (or n in our f(n) example) increases to infinity (mathematical
and constants are of little to no importance. That being said, if you have limits), the lower order terms and constants are of little to no
constants that are 2^9001, or some other ridiculous, unimaginable amount, importance. That being said, if you have constants that are 2^9001,
realize that simplifying will skew your notation accuracy. or some other ridiculous, unimaginable amount, realize that
simplifying skew your notation accuracy.
Since we want simplest form, lets modify our table a bit... Since we want simplest form, lets modify our table a bit...
@ -89,7 +91,7 @@ Exponential - a^n, where a is some constant
### Big-O ### Big-O
Big-O, commonly written as **O**, is an Asymptotic Notation for the worst Big-O, commonly written as **O**, is an Asymptotic Notation for the worst
case, or ceiling of growth for a given function. It provides us with an case, or ceiling of growth for a given function. It provides us with an
_**asymptotic upper bound**_ for the growth rate of runtime of an algorithm. _**asymptotic upper bound**_ for the growth rate of the runtime of an algorithm.
Say `f(n)` is your algorithm runtime, and `g(n)` is an arbitrary time 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 complexity you are trying to relate to your algorithm. `f(n)` is O(g(n)), if
for some real constants c (c > 0) and n<sub>0</sub>, `f(n)` <= `c g(n)` for every input size for some real constants c (c > 0) and n<sub>0</sub>, `f(n)` <= `c g(n)` for every input size
@ -139,7 +141,7 @@ No, there isn't. `f(n)` is NOT O(g(n)).
### Big-Omega ### Big-Omega
Big-Omega, commonly written as **Ω**, is an Asymptotic Notation for the best Big-Omega, commonly written as **Ω**, is an Asymptotic Notation for the best
case, or a floor growth rate for a given function. It provides us with an case, or a floor growth rate for a given function. It provides us with an
_**asymptotic lower bound**_ for the growth rate of runtime of an algorithm. _**asymptotic lower bound**_ for the growth rate of the runtime of an algorithm.
`f(n)` is Ω(g(n)), if for some real constants c (c > 0) and n<sub>0</sub> (n<sub>0</sub> > 0), `f(n)` is >= `c g(n)` `f(n)` is Ω(g(n)), if for some real constants c (c > 0) and n<sub>0</sub> (n<sub>0</sub> > 0), `f(n)` is >= `c g(n)`
for every input size n (n > n<sub>0</sub>). for every input size n (n > n<sub>0</sub>).
@ -188,8 +190,8 @@ _**asymptotically tight bound**_ on the growth rate of runtime of an algorithm.
Feel free to head over to additional resources for examples on this. Big-O Feel free to head over to additional resources for examples on this. Big-O
is the primary notation use for general algorithm time complexity. is the primary notation use for general algorithm time complexity.
### Ending Notes ### Endnotes
It's hard to keep this kind of topic short, and you should definitely go It's hard to keep this kind of topic short, and you should go
through the books and online resources listed. They go into much greater depth through the books and online resources listed. They go into much greater depth
with definitions and examples. More where x='Algorithms & Data Structures' is with definitions and examples. More where x='Algorithms & Data Structures' is
on its way; we'll have a doc up on analyzing actual code examples soon. on its way; we'll have a doc up on analyzing actual code examples soon.