Answers.Body: <h2>How badly written software can undo 120 years of computer hardware improvements.</h2>
  
  <p>First blow their minds with Moore's law: 120 years of progress from mechanical devices to the present day, there has been a $2^{60}$ improvement. </p>
  
  <p>Then show them how easy it is to lose all of this hard won, performance, improvement (in the hardware), by using poor software algorithms:
  If we are searching through a sorted list of $2^{30} \approx 10^9$ nodes, using liner search ($O(n)$), then we have the performance of $60$ year old computer, doing it the smart way (binary search($O(log n)$)). Even $2^{20} \approx 10^6$ nodes, is $40$ years of progress lost.</p>
  
  <p>Therefore if we want to see the benefit of hardware improvement, we need to not waste it. Also Moore's law will come to an end soon (as is true for all exponential growth. It is also true that most people will deny this, citing that it has not happened yet as evidence, until a short time after it happens).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T19:14:48.980Z
Answers.Text: I didn't DV, but it feels like you need to connect this back to the question a bit more.  It's also not entirely clear what you mean by "lost progress".
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T17:50:36.793Z
Answers.LastActivityDate: 2017-09-06T14:21:55.890Z
Answers.LastEditDate: 2017-09-06T14:21:55.890Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <p>I attack this problem with three "visits" over the course of two years with my students</p>
  
  <ol>
  <li>At our first brush with Complexity, I don't spend a ton of time motivating the study of it.  I introduce the notations of $\Omega$, $\Theta$, and $O$ (as well as briefly touching upon $\omega$, $\theta$, and $o$).  I show the difference between linear and binary search, and then explore four sorting algorithms: bubble, selection, insertion, and bogosort.  (This is fairly early on in the curriculum, and we haven't dealt with recursion yet, so I skip out on quicksort and mergesort.)  The last one makes them laugh, and makes the material at least have a point: some algorithms are just worse than others.</li>
  <li>Later in the year, we look at quicksort and mergesort.  At this point, again, we use this only as a chance to review the concepts and the notation.</li>
  <li><p>Near the beginning of the second year, I talk about why algorithmic study matters.  Computers get insanely faster over time, right?  (See Richard's answer for some eyebrow-raising numbers).  Since our computers are getting faster, it only stands to reason that things that are slow to compute today will also just get faster.</p>
  
  <p><em>"Au contraire!"</em> I cry, <em>"as our computers get faster, our algorithms are getting</em> <strong><em>slower</em></strong>, <em>you see!"</em>  What do I mean by this outrageous claim?  As our computers get faster, our hard drives also get bigger.  By necessity, we perform calculations with larger and larger data sets.    </p>
  
  <p>So, let's use high-end rendering as an example.  In 1980, Apple came out with the <strong>Apple III</strong> computer, which shipped with a whopping <strong>5 megabytes</strong> of diskspace.  It also used the 6502B processor.  It could perform about 0.43 million instructions per second (MIPS).  Today, hard drives come in at about 6 gigabytes, and 305 billion instructions per second.  My numbers don't have to be exact to make this work, though.</p>
  
  <p>If we processed a complex graphic that took about .5% of our hard drive using a $O(n^3)$ algorithm in 1980, that would be about 2,500 bytes of data, and it would take us roughly 9.25 years to complete.  That's awful!!  But if we did that today, (roughly 30 megabytes and 305 billion computations per second), it would take us over <strong>28 thousand years</strong> to complete.  We're trending the wrong way!  The problem is that, even at a relatively cheap function like $O(n^3)$, the growth due to data creep is just far faster than Moore's Law.  <em>Faster computers can't deal with correspondingly bigger problems if the $O$ sucks.</em></p></li>
  <li><p>Finally, a few weeks later, I talk in grand, futuristic terms about the Big Picture.  This is more to excite their curiosity than anything else. The three drivers of possibility with computers are, I argue, smaller transistors, better battery life, and better algorithms.  If you take a $O(n^3)$ algorithm and find a way to accomplish a similar task in $n^2$ time, that's a foundational enabler.  You don't become individually famous, but you change the world.  The Google Maps team didn't solve the Traveling Salesman problem, they developed algorithms that could get likely best answers without the guarantee.  The bottom line is that developing algorithms with better complexity literally enables us to do new things on practical timescales.  To paraphrase <strong>Heroes</strong>, <em>change the algorithm, change the world.</em></p></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T19:06:32.127Z
Answers.Text: Thanks Ben, this is great, I found your experience and your examples very interesting. +1 for you. I hope we can get a couple of answers more.
Answers.UserDisplayName: Kenny Barrera
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T22:51:44.200Z
Answers.Text: A polynomial $O(n^3)$ cannot possibly grow faster than the Moore's exponent. I understand what you are trying to convey, but I strongly suggest you to rephrase.
Answers.UserDisplayName: user58697
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-17T10:59:52.680Z
Answers.Text: @user58697 Ugh, that's a tricky wording.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-18T14:10:41.830Z
Answers.Text: @user58697 Is the wording now sufficiently clear?
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T18:59:18.597Z
Answers.LastActivityDate: 2017-08-17T10:58:42.757Z
Answers.LastEditDate: 2017-08-17T10:58:42.757Z
Answers.UserDisplayName: Ben I.
Body: <p>I was recently reading a really good article on this topic, and I realize that it could be a very good <strong>added value</strong> for students to understand better and appreciate (and eventually <strong>put in practice</strong>) all the theory that is behind Algorithm Complexity<sup><strong>1</strong></sup>. Certainly, not everyone will apply this in the future, since the most efficient way to solve a problem is not always required (although it should be). I think more people should be interested in this, since it has benefits in various ways. </p>
  
  <p>To understand my question a little bit better, I want to give an example of my own personal experience. </p>
  
  <blockquote>
    <p>From the very first moment I learned about Trees and Binary Trees (a
    long time ago), I don't know why, I hate them. I never thought about
    them like a solution to the many problems I had to face and resolve.
    Some time ago, I was told to recreate from scratch the Shannon–Fano
    encoding as an exercise. I enjoyed that so much! And of course, for
    that encoding, everything is based on trees. It was at that point that
    I was more interested in trees, how they work and their functionality
    to solve real life problems.</p>
  </blockquote>
  
  <p>So, in the <strong>same way</strong> the Shannon–Fano coding help me to understand better and made me want to go deeper in the tree's data structure theory, I'm asking for good motivating examples that might help others understand and want to learn more about Algorithm Complexity.</p>
  
  <hr>
  
  <p><sup><strong>1</strong></sup> Just to clarify, when I say Algorithm Complexity, I'm talking about all the theory and techniques that are available to know how efficient an algorithm is, and to compare that information with other results, thus leading to the most efficient way to solve a problem.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-06-19T07:38:39.800Z
Comments.Text: In real life (business) there is always a tradeoff between time/cost/difficulty of implementation+maintenance, and the benefit of a solution. For this reason, it is not the case that the most algorithmically efficient way to solve a problem is always required, nor necessarily the best for a given problem.
Comments.UserDisplayName: user985366
Tags: <lesson-ideas><best-practice><teaching-analogy>
Title: Good, Motivating Examples for Algorithmic Complexity
ThreadText: # Good, Motivating Examples for Algorithmic Complexity
  
  (Asked by: username_0 on 2017-08-16)
  
  I was recently reading a really good article on this topic, and I realize that it could be a very good **added value** for students to understand better and appreciate (and eventually **put in practice**) all the theory that is behind Algorithm Complexity**1**. Certainly, not everyone will apply this in the future, since the most efficient way to solve a problem is not always required (although it should be). I think more people should be interested in this, since it has benefits in various ways.
  
  To understand my question a little bit better, I want to give an example of my own personal experience.
  
  > From the very first moment I learned about Trees and Binary Trees (a
  > long time ago), I don't know why, I hate them. I never thought about
  > them like a solution to the many problems I had to face and resolve.
  > Some time ago, I was told to recreate from scratch the Shannon–Fano
  > encoding as an exercise. I enjoyed that so much! And of course, for
  > that encoding, everything is based on trees. It was at that point that
  > I was more interested in trees, how they work and their functionality
  > to solve real life problems.
  
  So, in the **same way** the Shannon–Fano coding help me to understand better and made me want to go deeper in the tree's data structure theory, I'm asking for good motivating examples that might help others understand and want to learn more about Algorithm Complexity.
  
  ---
  
  **1** Just to clarify, when I say Algorithm Complexity, I'm talking about all the theory and techniques that are available to know how efficient an algorithm is, and to compare that information with other results, thus leading to the most efficient way to solve a problem.
  
  **Tags:** lesson-ideas, best-practice, teaching-analogy
  
  > **Comments:**
  > **username_1**: In real life (business) there is always a tradeoff between time/cost/difficulty of implementation+maintenance, and the benefit of a solution. For this reason, it is not the case that the most algorithmically efficient way to solve a problem is always required, nor necessarily the best for a given problem.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2017-08-16. Score: 11 | Accepted answer
  
  I attack this problem with three "visits" over the course of two years with my students
  
  1. At our first brush with Complexity, I don't spend a ton of time motivating the study of it. I introduce the notations of $\Omega$, $\Theta$, and $O$ (as well as briefly touching upon $\omega$, $\theta$, and $o$). I show the difference between linear and binary search, and then explore four sorting algorithms: bubble, selection, insertion, and bogosort. (This is fairly early on in the curriculum, and we haven't dealt with recursion yet, so I skip out on quicksort and mergesort.) The last one makes them laugh, and makes the material at least have a point: some algorithms are just worse than others.
  2. Later in the year, we look at quicksort and mergesort. At this point, again, we use this only as a chance to review the concepts and the notation.
  3. Near the beginning of the second year, I talk about why algorithmic study matters. Computers get insanely faster over time, right? (See Richard's answer for some eyebrow-raising numbers). Since our computers are getting faster, it only stands to reason that things that are slow to compute today will also just get faster.
  
     *"Au contraire!"* I cry, *"as our computers get faster, our algorithms are getting* ***slower***, *you see!"* What do I mean by this outrageous claim? As our computers get faster, our hard drives also get bigger. By necessity, we perform calculations with larger and larger data sets.
  
     So, let's use high-end rendering as an example. In 1980, Apple came out with the **Apple III** computer, which shipped with a whopping **5 megabytes** of diskspace. It also used the 6502B processor. It could perform about 0.43 million instructions per second (MIPS). Today, hard drives come in at about 6 gigabytes, and 305 billion instructions per second. My numbers don't have to be exact to make this work, though.
  
     If we processed a complex graphic that took about .5% of our hard drive using a $O(n^3)$ algorithm in 1980, that would be about 2,500 bytes of data, and it would take us roughly 9.25 years to complete. That's awful!! But if we did that today, (roughly 30 megabytes and 305 billion computations per second), it would take us over **28 thousand years** to complete. We're trending the wrong way! The problem is that, even at a relatively cheap function like $O(n^3)$, the growth due to data creep is just far faster than Moore's Law. *Faster computers can't deal with correspondingly bigger problems if the $O$ sucks.*
  4. Finally, a few weeks later, I talk in grand, futuristic terms about the Big Picture. This is more to excite their curiosity than anything else. The three drivers of possibility with computers are, I argue, smaller transistors, better battery life, and better algorithms. If you take a $O(n^3)$ algorithm and find a way to accomplish a similar task in $n^2$ time, that's a foundational enabler. You don't become individually famous, but you change the world. The Google Maps team didn't solve the Traveling Salesman problem, they developed algorithms that could get likely best answers without the guarantee. The bottom line is that developing algorithms with better complexity literally enables us to do new things on practical timescales. To paraphrase **Heroes**, *change the algorithm, change the world.*
  
  > **Comments:**
  > **username_0**: Thanks Ben, this is great, I found your experience and your examples very interesting. +1 for you. I hope we can get a couple of answers more.  
  > **username_4**: A polynomial $O(n^3)$ cannot possibly grow faster than the Moore's exponent. I understand what you are trying to convey, but I strongly suggest you to rephrase.  
  > **username_3**: @username_4 Ugh, that's a tricky wording.  
  > **username_3**: @username_4 Is the wording now sufficiently clear?  
  
  ---
  
  ### Answer by username_2 on 2017-08-16. Score: 0
  
  ## How badly written software can undo 120 years of computer hardware improvements.
  
  First blow their minds with Moore's law: 120 years of progress from mechanical devices to the present day, there has been a $2^{60}$ improvement.
  
  Then show them how easy it is to lose all of this hard won, performance, improvement (in the hardware), by using poor software algorithms:
  If we are searching through a sorted list of $2^{30} \approx 10^9$ nodes, using liner search ($O(n)$), then we have the performance of $60$ year old computer, doing it the smart way (binary search($O(log n)$)). Even $2^{20} \approx 10^6$ nodes, is $40$ years of progress lost.
  
  Therefore if we want to see the benefit of hardware improvement, we need to not waste it. Also Moore's law will come to an end soon (as is true for all exponential growth. It is also true that most people will deny this, citing that it has not happened yet as evidence, until a short time after it happens).
  
  > **Comments:**
  > **username_3**: I didn't DV, but it feels like you need to connect this back to the question a bit more.  It's also not entirely clear what you mean by "lost progress".  
  
  ---
  
  