Many of the problems we will focus on have clear conditions. Efficiency is an important component of algorithms. In addition to run-time efficiency, we must also consider concepts such as space efficiency. As we have touched on already, efficient algorithms generally lack unnecessary details. Efficiency is not simply how fast an algorithm runs. There are many components to efficiency such as scale, location and how the algorithm is run. Thus, in forming a definition of efficiency we must use mathematics rather than simply relying on base intuition. Our approach to the speed component of efficiency will be the running time of the worst case. Worst-case analysis is easier to handle(less complications,often little uncertainty over what the worst case is), and tells us key information about the algorithm itself rather than simply the way in which it is run. Further, something that I brought up in class is that many programmers refuse to tolerate things ever going wrong. Thus, since worst-case running time holds the highest risk of consequences, it is logical to focus on it. Brute force search provides an excellent way to compare algorithms. Bts is simply iterating through every single possibility and stopping when we find one that works. Generally, this fails to give insights into problems and has high running time(simple matching problem n! pairs, so brute force is O(n!). Thus, we conclude that “An algorithm is efficient if it achieves qualitatively better worst-case performance, at an analytical level, than brute force search”. A weakness of this definition is that it is overly vague. One desirable property of algorithms is that when we scale up the input size by any factor x, the running time only increases by some constant c. This holds for any algorithms which run in polynomial time. Thus, a new and perhaps too simple definition of efficiency for an algorithm is “running in polynomial time”. There are benefits to such a concise definition such as the ability to classify problems as having an efficient algorithm or not. Overall, this section had a great deal of material but was easy to read/understand. I would rate it 8/10.

We analyze run-time in terms of steps(arithmetic operation, following a pointer, looking up an entry, or assigning a value to a variable. We will ignore the coefficients and all but the highest terms in our big-o notation. This is mainly because we want to emphasize similarity between algorithms, it is easier to derive,and at high(significant) running times, the nature of the largest term in the equation holds far more significance than the others. Asymptotic Upper Bound: T(n)=O(f(n)), where T(n)⇐c*f(n).O(n) is a familiar concept, where O stands for order and n is the highest-term with its coefficient removed. Asymptotic lower bound: show that a bound is the best possible instead of the worst possible(we will mostly be working with upper bounds). Asymptotically tight bounds are (basically) both upper and lower bounds.This section reviews the mathematical concepts of transitivity and sum and how they apply to bounds/asymptotic growth rates. As input size increases, logarithmic running times increase the slowest, then polynomial, then exponential(extremely fast, sometimes just described as “exponential running time”). Overall, this section was very hard for me to understand, in part because of the prevalence of dense equations. I would rate the ease of reading at between 4 and 5/10. I feel that my understanding of Asymptotic Lower Bounds and Asymptotic Tight Bounds is limited and I will need to continue studying the math for it to improve.

This chapter discusses the importance of picking the right data structures in terms of run-time. For instance, it reviewed how linked lists are constant for search and deletion yet not for access while arrays have constant access time but linear, O(n) addition. Overall, linked lists are therefore better for dynamic data subject to change whereas arrays are best when the data maintains its size. We can convert between arrays and lists in O(n) time and it is often worth it such as when the input comes in an inefficient format. We apply out learnings to the stable matching algorithm. To make the algorithm O(n^2), all components in the loop must run in constant time. To achieve this, we can represent free men as a linked list, we build an array to represent the indexes of the next choices of women,and use an array to hold women's current matches. Finally, we create a 2d array for men's preferences and a 2d array for women's preferences. To check who women would pick between two men, we just access two arrays which is in constant time. Overall, this section was quick and easy to read and understand. I would rate it at 8/10 to 9/10. One question I have is why the book didn't discuss possibly using other data structures for men and women such as stacks or dictionaries. Also, I am curious how memory would factor into this design in a real world scenario.