Instructions :
--------------

1.  When you extract O2.tar.gz, it will result in "O2" directory. Rename this
    directory to O2_<rollnum> where <rollnum> is your roll number. Follow this
    naming convention strictly.

2.  The questions are provided in 'O2_questions'.  There are three questions and
    the time alloted is two hours.

3.  Once you are done and ready to submit, make a tar.gz of the complete
    O2_<rollnum> folder and name it as "O2_<rollnum>.tar.gz".
    Optionally, you can run the provided 'repackage.sh' to get the above job
    done.

4.  Submit on moodle.


Testing :
---------

1.  The program 'test/run_test', if run without any arguments, will run all
    available testcases consecutively.  For each such testcase, it will write
    the output to a temporary file and compare it with the reference output
    (located inside dir. 'output').  In case there's any difference between the
    two files, the program outputs the differing lines only (in color) in the
    order -- your script's output followed by reference script's output;
    otherwise, it outputs nothing.

2.  It is also possible to provide arguments to the run_test script (see
    'test/run_test -h').  To run all tests for a particular problem #x, use :

    $ ./test/run_test -p x

    And to run test case #y of problem #x, use
    
    $ ./test/run_test -p x -t y

    run_test reports an error if either problem no. or testcase no. is invalid.


Guidelines :
------------

1.  Make sure your script executes 'out-of-the-box', i.e. by simply running
    './<script_file>' from the command line.

2.  Remember that the scripts will be run with the root dir (O2_<rollnum>) as
    the current working dir.  If you are using multiple files to write your
    source code in, make sure that the pathnames are correct.  All your source
    files MUST be inside src/.
    
3.  The scripts will be run on one of the OSL/NSL machines, so make sure you
    test your programs on any of these machines before submitting e.g. the
    installed version of python on these machines should support the function
    calls you make.

4.  Its usually a good practice to print to stdout intermediate stages of the
    computation to aid debugging.  However, forgetting to remove those 'print'
    statements before final submission can lead to erroneous output leading to a
    loss of points.  A neat solution is to define a variable (say 'debug') and
    set it to 1 while debugging and reset it to 0 before final submission.

    e.g.
    # debugging is on
    debug = 1

    # write your code here
    googol = 10**100

    # print variables
    if debug == 1 :
        print googol


5.  Passing the test cases provided does NOT guarantee full score on the
    problem.  For full score, your script must be able to handle the corner
    cases (cases like "what if n < 0?" etc.).  Having said that, the main
    emphasis will still be on solving the core problem, so don't spend too much
    time just to get the special cases working, especially if you think you
    could use that time to solve another problem.


6.  A Final word of advice : Use divide-and-conquer to break-down a seemingly
    hard/long problem into smaller pieces, rather than trying to solve the
    entire problem at one go.  If you have been asked to implement multiple
    options, start with the ones which are absolutely critical to running the
    program and then address the less critical ones.  That way, even if you run
    out of time, you will get partial credits for getting subproblems right.
