Class attendance is mandatory.
Attendance will be recorded. Be sure to sign the attendance sheet and return
it to the TA before leaving your lab session.
Attendance is reported on WebCT.
Each missed class counts as an unexcused absence towards the
attendance policy for the course. Three unexcused absences may constitute irregular withdrawal—I reserve the right to assign a grade of "Z" in these cases (which counts like an "F").
Due dates: Assignments will generally be due (unless otherwise noted, and pay careful attention to any exceptions!) by WebCT electronic submission, at 11:55pm, one week from the day they are assigned. Late penalties accrue from the due date (9/15) for students who do not submit their work on time.
Example: Assignment is due by 11:55pm, 9/15. If the assignment is turned in late, here are the penalties that apply:
9/16 |
21 |
2 points |
9/17 |
22 |
4 points |
9/18 |
23 |
8 points |
9/19 |
24 |
16 points |
9/20 |
25 |
32points |
9/21 |
26 |
64 points |
9/22 |
no credit since 27 > 100 points |
|
Note that even if you do not get any credit for the assignment, you often still need to complete it (if you hope to learn the material well enough to earn a decent grade on the exam.) Exam questions will often be based on assignments.
The issue of academic honesty is a little different in this class than what you may be used to in programming classes.
In this class, you are encouraged to work together, and you are encouraged to share code.
As long as you give credit (with comments, for example) and do not use other's code without written permission (e.g. an email from the other student, cc'd to the instructor and TA), you may share code and work together as much as you like.
However, this doesn't entirely eliminate the concept of academic dishonesty. Please note the following:
The following are considered academic dishonesty in CISC classes:
(1) Submitting someone else's script file as if it were you own.
(2) Providing your script file to another student without specific permission
from the instructor.
(3) Submitting something that is NOT a script file AS IF
it were a script file (e.g. typing in results into emacs that "look like"
the script file "would look").
For purposes of Computer Science, this is equivalent to
"falsifying results" in a science class, and is a MOST serious
violation of academic honesty.
(4) Editing a script file in any way with an intent to deceive.
(5) Because intent can be difficult to establish, it is better to
simply NEVER edit a script file for ANY reason, unless you have
specific permission to do so.
Some additional points:
(1) Typos in script files
Some students are tempted to edit a script file to "clean up"
typos on the command line that result in error messages, or
mistyped commands, where the backspace character makes the line look
messy etc.
DON'T FIX THIS BY EDITING THE SCRIPT FILE.
TAs should be tolerant of minor typos in commands, as long as it
is clear from the print out what is happening.
If the typos get so bad that the script cannot be read, the TAs
might get annoyed and take off points. In that case, you should
just redo the script file; don't edit it.
(2) Is editing a script file EVER permissible?
An example of a rare instance where editing a script file MIGHT 1be
permitted is a program that calculates the first 1,000,000 prime
numbers and prints them out. It might be permissible in such a
case to edit the script file to show only the first 10, and the
last 10, and then insert in between a few blank lines and the
message:
[ several hundred thousand lines of similar output omitted ]
There is no intent to deceive if you insert a message saying that
the output was edited and why.
However:
(1) Don't do this without specific permission.
(2) A better solution is to modify the program so that it
skips the output for all values between x and y, and give it the
values x = 11, y = 999990.
There is almost always a way to rewrite the program or the test
case to avoid the need to edit a script file.
As I recall it, at my new faculty orientation, UD President David Roselle mentioned that one of his top priorities as University President was to ensure that "everyone at UD has to be nice to everyone else at UD."
This may seem like a small thing, or even a cliche, but I've spent time in places where this was not a priority, and I can assure you that setting this as a priority makes a real difference.
I mention this especially in the context of lab, because I want to encourage you especially to treat your TAs with respect. Your TA is a qualified computing professional with a bachelors and/or a master's degree in Computer Science, and during your lab time, is your instructor, and serves as my representative.
Your TA is usually someone closer to you than I am in age and experience, and shares with you the experience of being a UD student. (TAs are usually pursuing a graduate degree, either an MS or Ph.D.) Because of this, TAs sometimes are on a first name basis with their students, and the atmosphere may be a bit more informal.
A certain degree of informality is acceptable as long as you don't forget that your TA is nevertheless in a position of authority. In the context of lab and office hours, you should interact with your TA with the same level of respect that you would show to me during lecture and office hours.
If you have a question regarding how your TA has graded an assignment, or any other matter, take it to your TA first.
If you are not happy with the response of the TA, you may bring the issue to your instructor.
However, do not engage the TA in a debate about policy; in particular, do not engage in any loud or disrespectful conversation that would tend to disrupt a lab or office environment where other students are trying to work. Section D.2.j of the University Code of Conduct prohibits "making, exhibiting or producing any inappropriate, loud or disruptive noise or behavior", and that certainly would apply to any mistreatment or disrespect shown towards TAs during lab or office hours.