Deprecated: (6.006) preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /afs/athena.mit.edu/course/6/6.006/web_scripts/fall08/wiki/includes/Sanitizer.php on line 1470
PSet3 FAQ - 6.006 Wiki

PSet3 FAQ

From 6.006 Wiki

Revision as of 02:09, 23 October 2008 by Juang (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Reminders

  • The work you hand in should be your own. 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

  • A handful of students have asked about what sorting algorithm to use on Problem B-1(a), and about the interpretation of "worst-case running time". The short answer is that you should use a sorting algorithm that operates as quickly as possible, in order to get the best possible worst-case running time. "Worst-case time" doesn't mean "what's the worst possible algorithm you can write": you can always write an arbitrarily horrible algorithm by, e.g., waiting for nn seconds, or worse, and then running a good algorithm. Instead, a problem like this means to find the worst-case time of an optimal algorithm that operates as described.

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


Personal tools