3/08 lecture feedback results, replies to some questions and comments. about 90 responses 1 1KnowDebugging: 1 1KnowDebugging: 1) very bad 7 1KnowDebugging: 2) bad 35 1KnowDebugging: 3) ok 39 1KnowDebugging: 4) good 8 1KnowDebugging: 5) very good 1 1LecDebugging: 1 1LecDebugging: 2) bad 42 1LecDebugging: 3) ok 40 1LecDebugging: 4) good 7 1LecDebugging: 5) very good 1 2KnowIdea-Analyze: 1 2KnowIdea-Analyze: 1) very bad 13 2KnowIdea-Analyze: 2) bad 50 2KnowIdea-Analyze: 3) ok 20 2KnowIdea-Analyze: 4) good 6 2KnowIdea-Analyze: 5) very good 1 2LecIdea-Analyze: 1 2LecIdea-Analyze: 1) very bad 6 2LecIdea-Analyze: 2) bad 50 2LecIdea-Analyze: 3) ok 28 2LecIdea-Analyze: 4) good 5 2LecIdea-Analyze: 5) very good 2 3KnowExample-Analyze: 1 3KnowExample-Analyze: 1) very bad 26 3KnowExample-Analyze: 2) bad 41 3KnowExample-Analyze: 3) ok 16 3KnowExample-Analyze: 4) good 5 3KnowExample-Analyze: 5) very good 1 3LecExample-Analyze: 1 3LecExample-Analyze: 0) don't remember seeing it 16 3LecExample-Analyze: 2) bad 51 3LecExample-Analyze: 3) ok 18 3LecExample-Analyze: 4) good 4 3LecExample-Analyze: 5) very good 1 5LecOverall: 5 5LecOverall: 2) bad 51 5LecOverall: 3) ok 32 5LecOverall: 4) good 2 5LecOverall: 5) very good 1 5LecPace: 4 5LecPace: 2) too slow 78 5LecPace: 3) ok 7 5LecPace: 4) too fast 1 5LecPace: 5) way too fast ---- q> interesting topics... ---- q> Overall, with the explanation of the new material as well as the q> presentation of debugging methods, the lecture was very helpful. q> I feel as though I have a strong understanding in the operator q> function, O(n), and the examples in lecture provided useful q> applications of the analysis in function steps. ---- q> I was a little unclear on the idea of big-Oh notation, even after q> reading the monster lecture sketch. I found it confusing, but the q> debuggin techniques were extremely helpful. ---- q> The overview of the techniques of analyzing performances seemed a bit q> much to do in one lecture. The ideas seemed beyond what we need to q> know, or can understand, and the concepts seemed far too complex to q> cover in one lecture. ---- q> I'm still confused about the PURPOSE behind doing flops and rates of q> growth in relation to the codes that we actually write in CS 100M. faster = better: would you rather wait 1 minute or 1 hour for a program to complete? smaller = better: would you rather use a program that requires all the memory in your computer or a program that uses only a small fraction of the computer's memory? doing really precise analyses is a pain. it turns out that performance is generally mostly determined by the rate of growth -- constant factors matter, but generally are of lesser importance. therefore, to evaluate peformance, it is often good enough to just analyze the rate of growth. ---- q> i was kind of confused today with the performance thing... ---- q> I don't see how this topic will relate to anything that we are doing. q> Why do we need to analyze performance? efficiency matters; see my response above. q> The topic just seems very q> random. If we are drawing near to the completion of the matlab q> portion, i think that you should focus more on clearing up any q> misunderstandings people have on Matlab so that they will be aptly q> prepared for the prelim ---- q> I think we should cover the analyzing stuff some more ---- q> The monster lecture sketch took a lot of time to read. Maybe it could q> have been prioritized so a person could read the most important stuff q> first, then continue if he or she had time. ---- q> Why didn't you tell us about $echo on$, $keyboard$, q> debugger/breakpoints before today!?!? Those are potentially the q> most useful commands you have taught us all semester. For future q> reference, teach these commands on during the first week of the course, q> and I'm not exaggerating. This was without a doubt the best lecture q> all semester. i do agree i should have taught debugging earlier, but here's why i didn't teach those commands from day one. 1. debugging can be problematic if taught at the very start of an intro programming courses. 2. it wasn't taught at all last semester. 3. the command window by itself already allows easy experimentation and debugging. ---- q> This was one lecture where I actually understood everything... ---- q> The example seemed trivial--I mean, can't you just look at the form q> of the code and tell the rate of growth is roughly proportional to q> the number of inputs? yes, i can. some people find analyzing cs100 programs easy. some don't. ---- q> If you could have shown us more examples of programs in which the q> function was of higher order (not just first order) with respect to q> x it would have helped clear things up a bit more. ---- q> I hope this new techniques would improve my debuging! ---- q> The echo, keyboard, and debugger techniques were qreat, I only wish q> I'd known about them a long time ago. They would have been very q> helpful in previous projects. ---- q> This lecture seemed to make sense. We'll see when I try to do the q> examples. ---- q> It was nice to see a demo about debugging, but the demo was extremely q> confusing since none of the variables had descriptions of what they q> represented. that was supposed to be one of the points of the demo: that was actual submitted code, which looks like it is on the right track, but is very confusing to read because of the lack of variable definitions. q> The way I think is such that unless I know what a program q> is doing, I am unable to debug the programming logic behind it. precisely. q> Could you please include variable descriptions with the program also - i already spent some time puzzling over it without success; i'm afraid it's too confusing for me to figure out precisely just right now. maybe after spring break... q> Question - Is the number of loops a program has directly q> proportional to the Oh notation - ie 4 loops = n^4??? no, but you're on the right track: basically, just multiply the slowdown factors for nested loops to get the big-oh answer. here are 3 examples, each with 3 nested loops, but none have running time $O(n^3)$. example 1: v = 1; w = 2; x = 3; for i = 1:10 v = v + v / n ^ i; for j = 1:10 w = w + n * v ^ j; for k = 1:10 x = x + v*w + i*n + j * n^2 + k * n^3; end end end run time is $O(10 * 10 * 10) = O(1)$ example 2: v = 1; w = 2; x = 3; for i = 1:n v = v + v / n ^ i; for j = 1:10 w = w + n * v ^ j; for k = 1:10 x = x + v*w + i*n + j * n^2 + k * n^3; end end end run time is $O(n * 10 * 10) = O(n)$ example 3: v = 1; w = 2; x = 3; for i = 1:n v = v + v / n ^ i; for j = 10*n:(5*n^2+7) w = w + n * v ^ j; for k = 1:n x = x + v*w + i*n + j * n^2 + k * n^3; end end end run time is $O(n * 5 n^2 * n) = O(n^4)$ ---- q> Understanding the "analyzing performance" from lecture is very vague... q> need to reread the posted lecture notes for a better understanding. ---- q> I didn't really understand how to apply the rate of growth and q> O(n) stuff. What was it for? ---- q> It may have been more productive to learn the debugging techniques q> earlier in the semester. It seems like a waste now that we are finished q> with matlab. some of the general ideas for debugging will apply to Java. ---- q> The explanations of these concepts was very good, but I still think q> we should be covering more problem solving skills and approaches to q> problems on projects rather than shortening the number of steps. q> It seems to me we should first know how to DO the programs before q> learing how to make them most efficient. ---- q> You could have gone a little slower on the part about analyzing q> functions, and could have briefly gone over the quiz at the end q> of lecture. ---- q> This lecture was very confusing... ---- q> I understand lines, and flops, but I didn't quite understand O(n) q> Use of computer in lecture is very helpful Using your hand to point q> to things on the board is also very helpful ---- q> I still don't quite understand what a flop is- one arithmetic (floating point) operation, e.g. addition, subtraction, multiplication, division, exponentiation. ---- q> good to see we are doing some computer science related q> ideas(algorithms, debugginng, big Oh, etc.) rather than programming ---- q> I liked that you introduced big o notation. I would love to see more q> algorithm analysis in the class, especially using mathematics to q> focus on the efficiency of the algorithm. we're about done now; CS211 does a lot more with analyzing performance. ---- q> This lecture was pretty helpful, though I am already familiar with q> many of the debugging techniques. ---- q> I don't understand how to get the f(n) functions for time and space q> (they are different, right?). Can you show or post some more examples, q> like the ones in E10 (I don't get them)? ---- q> I felt that $n$ could've been explained a little better when it was q> first introduced. I eventually figured it out as lecture went on. ---- q> it was helpful to get some more debugging suggestions - it is q> frustrating to search for errors! ---- q> The debugging techniques are really helpful. Maybe if they had been q> taught eariler in the ciurse, the projects (esp. P3) would have q> been easier. ---- q> i think that it was a little confusing when you used the echo command. q> For me at least, I didn't know echo etc. existed, so my partner and q> i have learned different ways to fix our problems. it might have q> been helpful to hear of those different editing commands earlier in q> the course. however, i don't know if it would have made things a q> lot more confusing at first. it was interesting to see the different q> ways to de-bug a problem. ---- q> could we just quickly run over "#flops" one more time? ---- q> using the computer is good but not when prof. yan seems surprised q> by what is happening on the screen. it makes him seem unprepared. q> i guess it shows the process that we should go through as we use q> matlab and find out different aspects of it. (yeah, the laptop computer gives me two major problems: 1. i can't type very well using that keyboard, especially if i am holding amic with one hand. 2. the projector requires a low screen resolution, which the graphics card on the laptop doesn't really support: colors are *really* washed out, so sometimes i can't see stuff. ) ---- q> it would have been helpful if you went over the last part of lecture q> more slowly, where you actually calculated the steps of a real program. ---- q> I am still confused on the big-oh notation and how to rank the q> polynomials as largest to smallest when they are the same exponent. q> I do not know what you mean by #lines and #flops either. if two polynomials have the same largest exponent, then they are equal under big-oh notation, e.g. $O(3 n^7 + 6 n^3 + 100 n^2 + 100000) = O(.00001 n^7 + n^3 + 5 n^2 + 1)$. ---- q> Good info for testing programs ---- q> The lecture went well, and was relatively easy to follow. However, I q> came late and had a seat in the back of the room and found it somewhat q> hard to hear and understand what was going on. ---- q> show how anaylzing performance relates to cs ---- q> I wish I had know about these tricks and Matlab functions a long q> time ago. ---- q> some of the examples seemed a little bit rushed and more vague q> than usual ---- q> It went well!