English subtitles

← 02-35 Cleaning Up Functions

Get Embed Code
1 Language

Showing Revision 1 created 04/23/2012 by Amara Bot.

  1. Now, when we're designing a program, we're thinking at multiple levels.
  2. We're thinking about different aspects of that program.
  3. For example, we always have to think about is the program correct.
  4. Does it implement what we want it to implement?
  5. We saw in the zebra puzzle that we also want to worry about is it efficient.
  6. Maybe we have a correct program, but it takes an hour,
  7. and we'd rather have a program that takes thousandths of a second.
  8. We also have to worry about the debugging process
  9. of as we're developing the program, we're building up all sorts of scaffolding
  10. to make it run properly that maybe we won't need later.
  11. Traditionally, we write our program.
  12. Some of what we're written has to deal with having it be correct.
  13. Then some of the code interspersed in there deals with efficiency.
  14. Now we've talked about adding further code that deals with debugging it.
  15. We end up with this mess that's all interleaved, and wouldn't it be nice
  16. if we could break those out so that some of the debugging statements were separate,
  17. some of the efficiency statements could live someplace else,
  18. and the main sort of correctness program could, say, stay distinct from the other parts.
  19. This idea is called "aspect-oriented programming."
  20. It's an ideal that we can strive for.
  21. We don't get it completely, but we should always think of can we separate out
  22. these different aspects or concerns as much as possible.
  23. What I want to ask is if I've written the function this way
  24. as this big generator expression rather than as nested statements,
  25. I can't have count equals count plus 1 statements inside here,
  26. because there's no place to put something inside a statement,
  27. and I'd like to separate the counting as much as I can from the puzzle
  28. to do the minimum amount of damage or editing to allow me to insert
  29. these bookkeeping nodes that do that counting. Let's think about that.
  30. What would be the right way to do that?
  31. I'll tell you what I came up with. This is the second-best answer I came up with.
  32. That's to say, well, what am I doing?
  33. I'm counting iterations through the orderings, so maybe the place to
  34. insert my annotations is right here.
  35. I want this to be a debugging tool.
  36. For debugging tools, I'm willing to have shorter names,
  37. because they're things that really aren't going to stick around.
  38. I'm going to use them for a while, and then I'm going to get rid of them.
  39. I'm willing to have a one-character name here, although it bothers me a little bit.
  40. I can always rename it as something else.
  41. What I'll do is I'll just insert this call
  42. to the function c around each of my uses of orderings.
  43. I'm going to insert 1, 2, 3, times 5, 15 characters.
  44. There we are. I think that's a lot less intrusive than putting in
  45. a lot of count equals count plus 1 statements.
  46. I'm pretty happy with that.
  47. What I've done here is defined a function called "instrument function,"
  48. which will count the calls that it takes to execute the calling of a function with the arguments.
  49. I haven't shown you the definition of c yet,
  50. but when I show it to you, you'll see that it keeps track of two counts--
  51. the number of starts, the times we started an iteration, started the for loop,
  52. that was measured with the c function, and the number of items that we got through.
  53. How many times did we go through that for loop?
  54. We initialize those counts to 0, we call the function, and then we say what do we get back.
  55. With the zebra puzzle, it only took us 25 iterations over 2,700 items.
  56. Puzzle2--this was the definition for when we took the original definition
  57. and then moved only one of the constraints up in the ordering.
  58. That gave us this number of iterations and items.
  59. I didn't show the puzzle where none of the constraints are moved up.
  60. That would've taken even more.
  61. We see even here quite a reduction in the number of iterations in the counts,
  62. and this tells you how efficient we are.