From ...
From: Erik Naggum
Subject: Re: Mergesort: why's it efficient?
Date: 1996/12/06
Message-ID: <3058824781104480@naggum.no>#1/1
X-Deja-AN: 202599123
references: <57j5dh$sh3$1@goanna.cs.rmit.edu.au> <6M5-4oabJaB@09.viking.ruhr.com> <6MIHn7irJaB@09.viking.ruhr.com> <01bbe2fb$c692d1c0$c761e426@DCorbit.solutionsiq.com>
organization: Naggum Software; +47 2295 0313; http://www.naggum.no
newsgroups: comp.lang.c++,comp.sys.mac.programmer.help,comp.lang.lisp
* Dann Corbit
| If the problem is tiny, it may not matter what sort of algorithm, since
| all will finish in a blink. If the problem is huge, then it matters
| enormously, because for some problem size, O(N*log(N)) will always be
| better than O(n^2).
it appears that many people don't undertand the O notation. O indicates
complexity, not execution speed. the execution speed depends on a constant
factor that is insignificant compared to the variable factor as it grows
without bound. a function of complexity O(n log n) may have a constant
factor (k) that makes execution time (or other resources) _higher_ than a
function of complexity O(n^2) with a much smaller constant (c) as long as
the relation
k n
--- >> -----
c log n
holds. however, your statement that O(n log n) will _always_ be better
than O(n^2) does not hold, precisely because of the possibility of the
above relation.
since Andrew Koenig surprised many by limiting n and then arguing how
insignificant log n is compared to n, as if this is anything but obvious,
others have followed in his muddled footsteps and also conveniently forget
the constant factor or the actual meaning of the O notation. I'm frankly
amazed that this is possible for even half-educated computer scientists.
the O notation does _not_ indicate execution time. the O notation is the
_simplest_ function that yields an upper bound on the _relation_ between
the length of the input and the execution time (or space).
I recommend that Andrew Koenig and others who have been confused by him
read Alfred V. Aho and Jeffrey D. Ullman's excellent book "Foundations of
Computer Science" (Computer Science Press, 1992; ISBN 0-7167-8233-2), which
has grown out of the course CS109 -- Introduction to Computer Science at
Stanford University. the topic of chapter 3 is the running time of
programs. section 3.10 specifically analyses merge sort. it should be
instructive to more than the target audience of students, and any
programmer worth his salt _should_ be able to understand this chapter with
little effort. in particular, their treatment of constants and of the
simplification involved in the O notation is fundamental knowledge and
_should_ not come as a surprise to anyone who has been following these
discussions. _please_ take the time to look up this book. (Dr. Aho and
Dr. Ullman have both worked at Bell Labs, which is why I chose this
textbook over many other candidates. this will hopefully make it harder
for Andrew Koenig to ignore them, as he is wont to do for most everything
else shown to correct or contradict his inaccurate statements.)
#\Erik
--
Please address private replies, only, to "erik". Junk mail, spam,
stupid flames, courtesy copies, etc, should be sent to "nobody".