PSet4 FAQ

From 6.006 Wiki

Reminders

• 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 generally not accepted. We have been lenient about the deadline so far, but starting with this problem set, we will become significantly less forgiving. 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.

Tips

• You will not need to understand the rubik.py code completely to finish your problem set. A good function to know though is perm_apply().
• Self-loops are back edges. Although we hedged a little on that point in lecture, CLRS specifically says that they are. Conceptually, they behave just like back edges; it is an edge that, when encountered, goes "back" to a vertex that you're currently in the process of visiting. (If you're one of the couple people who assumed that self-loops are not back edges, and who turned in your pset Sunday night or earlier, we won't penalize, and won't require you to go back and fix it ... although of course you're welcome to.)

Staff clarifications and Errata

• The docstring in level.py should read "quarter twists and half twists" as stated in the problem set.
• Submitting the "Answers" PDF file to the website is optional. While we would appreciate a brief write-up and description of your code for Part A, we don't require it. Of course, the more easily we can understand your code, whether through in-line comments or a separate description, the more likely we are to be generous when grading it.

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