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.
- November 19: Make sure on Problem 3 (Even-length paths) that when you transform the graph, your new graph still has O(E) edges. One common approach results in up to E2 edges, which is bad news for your running time.
- November 18: "Why is my code slow?" The most common reason we've seen for slow code on this problem set is that you're doing too much work. The short path test should run in less time than the long path test. If they are taking equal amounts of time, odds are that you're running Dijkstra until you've visited every node—is this necessary? How can you avoid doing that?
Staff clarifications and Errata
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