CS302 -- General Information

James S. Plank


Grading

The grading break down will be something like 47% homeworks, 3% lab attendance, 25% midterm, 25% final exam. See the final grades file for how the number grades translate into letter grades.

Lab Stuff

Lab attendance is mandatory. Labs are partitioned into two 90 minute sessions. In the first, you will do one or more Topcoder problems. Your attendance won't count unless you finish the problems that you are required to finish, so if you are 45 minutes in and struggling, make sure you ask the TA's for help.

In the second 90 minutes, the TA's will help you with the next lab. I know from experience that a bunch of you will be working on the previous lab, even though it was due the night before, and you will have questions. The TA's will answer those, so long as no one has questions about the current lab. In other words, current lab questions get strict priority over previous lab questions.

I really don't care which lab session you attend, so long as you attend one of them. In the first few weeks, space will be tight, so you may want to bring your laptop, especially if you prefer to work on it rather than a Hydra machine.


Homework Stuff

I typically call homeworks, "labs." Sorry if that's confusing -- you can typically differentiate homework-lab vs. lab-lab from the context in which the word "lab" is used.

In general, labs will be due at midnight on sunday night. I won't let you work all night on Sunday night, because then you either sleep through lab on Monday, or you skip it. The lab deadlines will be firm. The late policy is simple: you lose 10 percent for each day (uncompounded) that the lab is late. The TA's will be grading on Fridays, so that's when you will get your lab back.

There will be a correctness script for each lab. That is what the TA's will execute to test the correctness of your code. It will be worth 90% of your grade for each lab. These scripts help you in three ways:

  1. You will have an easier time testing your code for correctness.
  2. The TA's turnaround time on grading will be quicker.
  3. The TA's effort in grading will be less, freeing them up for more office hours.

You must perform your labs alone. Obviously, you may talk about your labs with the TA's and with other students, but when it comes time to write the lab, you must write your own code. Otherwise, it is plagiarism.

A corollary of this is to protect your directories so that no one can read them. If you do all of your work in ~/cs302, then right now, do:

UNIX> chmod 0700 ~/cs302
If someone cheats off of you, chances are we cannot determine that, since file access times can be modified. In the past, when I have discovered cheating, both parties (cheater and cheatee) get zeros. Protect yourself.

TA's and Help

The primary place for you to receive help with your labs is during lab time and during the TA's office hours. The class is organized so that you can get help starting your labs during the lab time. As you work on your labs during the week, you should solicit help and comradery from other classmates, and the TA's will have office hours every day during the week. You can try to contact TA's during non-office-hours as well -- However, they are students taking full course loads, so their responses will be best effort.

Over the weekend, you're back on your own, and again you should solicit help and support from your classmates. You may try to email the TA's, but again, they may not respond. They have lives too. Obviously, use Piazza at all times -- often that will get you more rapid help than emailing TA's.

I shouldn't have to write this, but history requires me to. While I love you, and the TA's love you, this class is not our only responsibility during the semester. Similarly, you are taking other classes, so this class is probably not your only responsibility. Think about that when you do things. For example, a few years ago, a student resubmitted a late lab whose score was obviously going to be lower than his first submission. He submitted it because he was proud of finishing it, and wanted the TA to know. The TA, who was swamped with other classes, simply regraded the submission and gave the student the lower score. The student was outraged -- all he wanted was a pat on the back!! Who was at fault? Everybody had good intentions. However, the student should have used the proper channels -- if he wanted an "attaboy," he should have emailed the TA seperately or gone through office hours. This may seem picky, but a matter like this cost everyone time and emotional drama. Including me. The bottom line is to think about your actions before you do them.


Help Each Other!

You are all brothers and sisters in this class. While I'm not the biggest fan of interpersonal interaction and conversation, even I will admit that you learn many unexpected and valuable things through interaction. This is when you are both soliciting help and providing it. I encourage you to try to help each other. Piazza is a great vehicle for this.

My Pet Peeves

I go over these on the first day of class, but I figure it's time to write them down so that you have reference material. Every teacher has his/her own style, and after 20+ years of teaching, I know mine pretty well. This list doesn't apply to all teachers -- just me.

My Non-Pet Peeves


C++ 98

We are using C++ 98. Your TA will compile your code with the -std=c++98 flag, and if it doesn't compile, it is getting kicked back to you with late points. That means that when you develop your code, you need to make sure that it compiles with -std=c++98.

Mitigating your emotions with this decision. I understand that 1998 was a long time ago, and that in the years between then and now, technology and computer programming have come a long way. You may worry that what you are learning is going to put you at a disadvantage in job applications. I believe that this is unfounded. In this class, you not only are learning fundamental algorithms that give you tools for solving all sorts of computer-related problems, but you are also learning how to program in such a way that you actually understand what you are doing, and for the most part what your computer is doing. Learning to program in the manner in which I am teaching you makes you a stronger programmer, and later in your life, if and when you decide to move beyond what I am teaching, you will be better for it.

Yes, I am old. I first learned to program as a college freshman in 1984. I don't program using the newest standards and tools. However, within the recent past (< 5 years), I have managed a very large, long-lived, multi-developer programming project; I have done thorough examinations of the source code of very successful computer companies; I have exported open-source code that has been in use by many of the top companies in the business. So, even though I am old, I am wise, and I don't restrict you to C++98 because I am old, but because I am wise. I believe very firmly that I am doing you a service with this decision.

A corollary of this is that when you do your job interview, and they make you program, you can let them know that your dogmatic professor made you program in C++98. If that will be a problem for hirability, then you'll have to bone up on C++11 (or, god fobid, a later version) on your own.


Commenting Your Code

You will be graded on commenting. Something like 10%. You should comment your code by blocks of comments at the beginning of your files, and before subroutines. Variables should be commented inline. You may also want to comment large blocks of code. You should not comment with a ``running commentary'' to the right of your code, because that is often useless, hard to maintain, and disconcerting. I have seen comments like the following:
  if (i == 0) {               /* If i equals zero */
    return;                   /* then return */
  } else {                    /* otherwise */
    exit(1);                  /* exit with a value of one */
  }
The above is an extreme example, but don't let it happen to you.

Here's an example of what I would consider a well documented program:

 
#include <stdio.h>

/* sumnsquared.c
   Jim Plank
   August 23, 1998

   This program prompts for and reads a value n from standard
   input, and then calculates and prints the sum of squares
   from one to n.  It uses a for loop instead of using the 
   closed form expression.
   */


main()
{
  int n;                   /* The value */
  int sum;                 /* The running sum of squares */
  int i;                   /* An induction variable */

  /* Prompt for and read in a value of n */

  printf("Enter a value n: ");
  fflush(stdout);
  if (scanf("%d", &n) != 1) {
    exit(1);
  }
  
  /* Calculate sum for each value of i from one to n */

  sum = 0;
  for (i = 1; i <= n; i++) sum += (i*i);

  /* Print the final summation */

  printf("%d\n", sum);
}

Here's a guide on indentation that you may want to follow.