6.01 Staff

Massachusetts Institute of Technology
Dept. of Electrical Engineering and Computer Science
Spring Semester, 2008
6.01: Introduction to EECS I

Comments on Nanoquiz 1

Nanoquiz 1 was pretty straightforward, and most people did well. As problem 2 on behaviors showed, you'll need to study the design lab handout and come to lab prepared to start working. You should expect future nanoquizzes to continue to include questions about the design lab descriptions.

Here are some comments on issues revealed by the quiz answers. While we didn't necessarily take points off for all of these, they are nonetheless worth paying attention to:

Problem 1: Mean of a list of numbers

Most people realized that you have to convert to floating point in order not to get tricked by Python's integer division. You can covert by explicitly calling Python's float operations, or by adding 0.0, or by multiplying by 1.0. (Or by waiting until next fall when the new version of Python comes out that removes this annoyance.)

In scanning through the elements of the list, you can keep a counter and scan over the indices, like this:
```
while i < len(numList):
   result = result + numList[i]
```
or scan directly over the the list elements themselves:
```
for n in numList
   result = result + n
```
While we didn't take off points, the second one exhibits better style: There's no reason to explicitly introduce the counter i if you're not interested in the specific positions of elements in the list. Actually, for style, list comprehension or map and reduce is better than either: there's no need to write an explicit loop here. Of course, you can also sum a list without using a loop at all by writing
```
sum(list)
```

Some people wrote
```
[x for x in list]
```
which just gives you x.

Problem 2: Defining a behavior

The most serious error here — and one that lost a lot of credit — was writing something that did not meet the spec of a behavior as described in the lab notes. A behavior, according to the specification, is something that takes in sensor data and returns an action. Common errors here were writing code that calls doAction, or that sits in a loop and tests. We graded these kinds of errors harshly to emphasize that when you write code meant to be part of a system, you need to pay careful attention to how the code is supposed to fit together with the rest of the system. Here, the job if a behavior is to produce an action, not to do the action or to issue direct motor commands.

We also took off for missing return statements. We realize that Python's insistence on writing return is annoying. You'll be making this kind of error constantly, so you should be on the alert for it. Also, in this problem forgetting return might also indicate a misunderstanding of the spec.

Many people wrote tests like this:
```
if senseAhead(sensorValues) == True
```
We didn't take off points, but it's better to write
```
if senseAhead(sensorValues)
```
Remember that in Python, the == comparison returns a value that can be tested directly by if. There's no need to explicitly compare it with True or False.

Another common error was to write things like
```
while senseAhead(sensorValues) ...
```
rather than
```
if senseAhead(sensorValues) ...
```
While we didn't take points off, this might indicate a serious conceptual error about how SoaR brains work. In a brain, the job of the step procedure is to test the sensors, think, and issue a single motor command. The SoaR system then arranges for that step to be run over and over. This is the transducer model for programming embedded systems, as described in the course notes.
The step procedure itself should not sit in a testing loop. Several people ran into this problem in doing the lab, when their robot seemed to be unresponsive.