teaching machines

CS 145 Lecture 14 – Collision Detection

October 5, 2015 by Chris Johnson. Filed under cs145, fall 2015, lectures.

Agenda

• what ?s
• a development recipe
• rectangle

Note

Our task today is come up with a workflow for preserving our sanity as we write code. Here’s your task:

As you solve the problem of colliding rectangles, think about what you are doing to solve the problem. Write down a list of the general steps that one might follow to complete any problem.

Following is my recipe for “suckcess”—the cessation of suckiness. Teaching machines can be very a enjoyable process, but only if you go about it in a certain way.

1. What is your goal?
   The problem: frustrated programmers don’t know what they’re trying to do. Part of the problem with this is that the academic setting is artificial. I’m giving you goals. However, it’s often the case that in industry you don’t get to pick your own goals either—at least not all the time. The first step is getting a reasonably clear picture of what your code needs to do. Answering this question for a method reveals the method’s name and return type.
   show
2. What data do you have?
   Rarely does our code have enough information in and of itself to accomplish a task. Those who depend on us are going to have to give us some data on which we can operate. For a method, answering this question will give us our parameters.
   show
3. How can you visualize the problem away from the computer?
   We do not do our best thinking at a computer. Psychologically, seeing a bunch of red from our development environment is discouraging and prohibits us from freely experimenting. We need to be able to draw and make mistakes. We are a species that has a whole lot of builtin capacity for understanding physical entities. How can we model the problem with objects around us?
   show
4. What’s a small, testable subproblem I can solve? “A fool’s eyes wander the whole earth…” We don’t solve a whole problem at once. We take lots of small sure steps that we can verify through testing rather than wild jumps.
   show
5. What’s another small, testable subproblem I can solve?
   show
6. What’s another small, testable subproblem I can solve?
   show
7. What’s another small, testable subproblem I can solve?
   show
8. What’s another small, testable subproblem I can solve?
   show
9. What’s another small, testable subproblem I can solve?
   show
10. What’s another small, testable subproblem I can solve?
    show
11. What’s another small, testable subproblem I can solve?
    show
12. What’s another small, testable subproblem I can solve?
    show
13. What’s another small, testable subproblem I can solve?
    show
14. What’s another small, testable subproblem I can solve?
    show
15. What’s another small, testable subproblem I can solve?
    show
16. Go back to step 5.
    show
17. My code works for my tests, but what if my grandma or arch nemesis tries it? You are biased in your favor. Code that works for you may not work for someone else. It may not match the specification, it may use misleading names, it may make assumptions about the parameters, and so on. The more you doubt yourself the stronger your creations will be.
    show

Code

…

Haiku