From 6.006 Wiki
- The work you hand in should be your own. Don't copy code! Don't let anybody else copy your code! Don't! You'll get caught, and we won't be happy. And then you won't be happy. As you might expect from an algorithms class, we have algorithms that detect similarities in submitted code. We run these algorithms against all code submitted in this and previous semesters. If you have any questions about appropriate collaboration or use of code from other sources, we urge you to consult the staff, in order to help avoid misunderstandings later.
- Late submissions are not accepted. There is a grace period, owing to clock skew and what not, but consider it to be on the order of minutes, not hours. If you don't submit by the time we pull the problem sets from the website, you're out of luck, so we recommend you try to be on time.
Staff clarifications and Errata
- There's an error in the examples for Problem 2 on PS6-B - I forgot to verify the example after tweaking it a little, and as a result it's wrong. The third example should read:
"For the expression (-3) x 3 + 3, the optimal ordering is ((-3) x 3) + 3 = -6."
- For problem 1 on PS6-B, part (b) does not necessarily require you to use the convexity of h. Simply describe a solution that is more efficient than "run the algorithm from part (a) k times."
general debugging hints
- adding asserts to your code can help you to ensure that values are what you expect them to be at all times
- write your code modularly: use submethods for any non-trivial repeated or similar code.
- write unit tests for each of the submethods written
- separate complicated computations into smaller pieces which can then be asserted on.
- try to find out where the time is going, are some methods being called more often than you expect them to? do they take longer to execute than expected?
- If you'd like, try out pdb and let us know if you like it