USC CSD Home
 

Homeworks - CSCI 570, Fall 2011, DEN Session

There are two types of homework assignments: Written homeworks will not be collected or graded. They will be problems from the required textbook (Kleinberg & Tardos). You are expected to work on them since exam questions may resemble these problems!

Programming assignments, on the other hand, will be collected and graded.

 
Written Homework Assignments
On all the written homework assignments, when you are asked to give an algorithm, in addition to the algorithm, you must also give (a) a proof of its correctness and (b) an analysis of its complexity.

All homework assignments are from Kleinberg and Tardos, 1st edition, unless otherwise stated.

  • Chapter 1 (Representative Problems):  Read Chapter 1.  Problems 1, 2, and 7. [solutions]
  • Chapter 2 (Algorithm Analysis):  Read Chapter 2.  Problems 3, 5, and 6(a,b). [solutions]
  • Chapter 3 (Graphs):  Read Chapter 3.  Problems 2, 3, and 12. [solutions]
  • Chapter 4 (Greedy Algorithms):  Read Chapter 4.  Problems 3, 7, 17, and 28. [solutions]
  • Chapter 5 (Divide and Conquer):  Read Chapter 5.  Problems 2 and 3. [solutions]
  • Chapter 6 (Dynamic Programming):  Read Chapter 6.  Problems 1, 5, 10, and 20. [solutions]
  • Chapter 7 (Network Flow):  Read Chapter 7.  Problems 7, 12, 16, and 29. [solutions]
 
Programming Homework Assignments
(Please note that access to homework assignments is restricted.)
 
General Information about Programming Assignments
(Please note that access to programming assignment related information is restricted. You should have received a password in your e-mail after you have registered with the class mailing list.)

The programming assignments will be C/C++ code to be developed on a UNIX environment. No other programming language will be accepted and your program must compile and run with a Makefile as is on a nunki.usc.edu. You must be familiar with the UNIX development environment (vi/pico/emacs, cc/gcc or g++/cxx, make, etc.)

Please read the programming FAQ if you need a refresher on C/C++ file I/O and bit/byte manipulications.

You should use your USC accounts and preferably work on the Solaris machines in the ISD computer rooms for testing. The final (submitted) program must run on nunki because we are going to test it in that environment. But you should not do the whole program development there, as nunki is a general purpose server - under heavy use from many students. We will only grade from a grading account on nunki, so you must make sure your program runs correctly from any account on nunki. We cannot run your program from your account for the purpose of grading.

Late submissions will receive severe penalties. Due to clock skews, electronic submissions of projects and homeworks assignments will be accepted within 15 minutes after the specified deadlines without penalties. If you submit with the next 24 hours, you will receive 75% of your grade. Although in the first 50 minutes of this period, you will only lose 1% of your grade every 2 minutes. You will receive a score of zero after the first 24 hours (and your assignment will not be graded).

All submissions will be timestamped by the submission server and receipts will be issued. Whether your submission arrived to the server by the deadline is determined by the timestamp. Please keep your receipts.

If a student signs up late for this class, he/she is still required to turn in all the assignments on time or he/she will receive a score of zero for these assignments. No exceptions! This requirement also applys to students on the wait list.

You must follow the Electronic Submission Guidelines when you submit programming assignments. Please note that this is a brand new procedure and very different from previous procedures. Please make sure you read the output of the bsubmit program carefully. It should look similar to the sample output given on the bsubmit page. The timestamped upload ticket issued by the Bistro server is a proof that the server has received your submission (and you do not need additional proof). You should also verify what you have submitted is what you intended to submit by following the Verify Your Submission procedure. Please note that it is your responsibility to ensure that you have submitted valid submissions and that you have received timestampted upload tickets for them.

 
Using Code from the Internet
Personally, I think it's best that you write your own code from scratch. On some programming assignments, you may be allowed to use publically available source code downloaded from the Internet. When you download such source code and put it in your file, you must do the following immediately to surround the source code you have downloaded:
    /*
     * Begin code I did not write.
     * The code is downloaded from <URL>
     * If the source code requires you to include copyright, put copyright here.
     */
    [ downloaded source code ]
    /*
     * End code I did not write.
     */
If you decide to make changes to the downloaded source code, you should change the phrase "This code is downloaded from ..." to "This code is derived from ...".

Another important thing is that the <URL> mentioned above must be the URL where I can see the downloaded source code (and not some top-level web site). Also, if the source code is publically available, it must not require any user ID or password to see the code.

If you only mention that you have use downloaded code from this URL and that URL in your README file, you may lose a lot of points. Please read the grading guidelines carefully to see how many points you can lose. If you want to make sure that you don't lose points for any downloaded source code, please add the comment blocks mentioned above for EVERY block of source code you have downloaded.

Finally, code done by students in previous semesters cannot be used no matter what.

 
Modifications after Deadline
You are allowed to submit modifications via e-mail to the instructor, within 24 hours of the submission deadline.

One line (128 characters max) of change is defined as one of the following:

  • Add 1 line before (or after) line x of file y
  • Delete line x of file y
  • Replace line x of file y by 1 line
where x is a line number and y is a specified file. The first 3 lines of modifications are free of charge. Additional modifications cost 3 points per line.

Afterwards, additional modifications cost 12 points per line until 7 days past the submission deadline. After 7 days past the submission deadline, an additional modification costs 30 points per line.

Please note that this applies to source code, Makefile, and README files.

 
Segmentation Faults and Bus Errors
I often get questions regarding segmentation faults and bus errors. Sometimes, these occue when one calls library functions such as gethostbyname(). Some students think this is some kind of a networking bug. Well, it's often not. I will try to answer this type of questions here once and for all.

Chances are that you have corrupted memory. This usually means that you have corrupted memory a while back. It just happened that when you call gethostbyname(), the corrupted memory caused a bus error or the execution of an illegal instruction. Bus errors and illegal instructions are basically the same thing as segmentation faults.

How does one corrupt memory? You can write beyond an allocated memory block. You can free the same object twice. You can free an object that was not allocated. You can write to an object that's already freed. These bugs are hard to find because most of the them you only see that there is problem long time after you have corrupted memory. If you have access to a professional/expensive debugging tool, it may be helpful. Otherwise, you just need to do binary search and see where the bug(s) might be. There's no magical cures in debugging memory corruption bugs.

One thing you might try is to temporarily turn off memory deallocation (if you suspect that you have freed the same object twice or freed an object that was not allocated). You can do the following to define free() as a no-op in a common header file when you are debugging:

    #define DEBUGGING_MEMORY_CORRUPTION
    /* comment out the above line when you are done debugging */
    #ifdef DEBUGGING_MEMORY_CORRUPTION
    #ifdef free
    #undef free
    #endif /* free */
    #define free
    #endif /* DEBUGGING_MEMORY_CORRUPTION */

As your code gets more and more complicated, and you are not very careful in managing your resources, you may get more of these. This is one reason why you want to keep your code nice and clean.

On nunki, you can try efence. There is a copy installed in:

    ~csci551b/public/efence/2.2/ElectricFence-2.2.2-15
Please read:
    ~csci551b/public/efence/2.2/README-solaris
I have not tried this library and I do not know if it's suitable for our programming assignments. But I've heard good things and bad things about it. Please try it at your own risk.

If you develop your code on a Linux, you can try valgrind. I have not tried this tool and I do not know if it's suitable for our programming assignments. But I've heard good things (e.g., easy to use) and bad things about it (e.g., it only runs on Linux). Please try it at your own risk.

Also, if you want to try these, incorporate them in your programs as early as possible. Don't start learning it when bugs are happening and deadlines are approaching.

 

[Last updated Sat Sep 19 2020]    [Please see copyright regarding copying.]