Lab 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.
Lab attendance is reported on WebCT.
Attending a lab other than
the one to which you are assigned will not meet your lab attendance obligation,
unless you have advance permission of the TA by email (this will be granted
only in unusual circumstances, at the TAs discretion, and Prof. Conrad must
be cc'd on the email.) In any event, attending a lab other than the one to which you are assigned is on a "space available" basis; you may do so only if there is room after all students attending their correct lab session have found a place to work.
Each missed lab and lecture counts as an unexcused absence towards the
attendance policy for the course. Three unexcused absences will result in
automatic failure of the course.
Example: Student attends lab01 on 9/8. Lab is due by 11:55pm, 9/15. If the lab is turned in late, here are the penalties that apply:
9/16 |
2^1 |
2 points |
9/17 |
2^2 |
4 points |
9/18 |
2^3 |
8 points |
9/19 |
2^4 |
16 points |
9/20 |
2^5 |
32points |
9/21 |
2^6 |
64 points |
9/22 |
no credit |
since 2^7 > 100 points |
Note that even if you do not get any credit for the lab, you 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 lab material.
There have been some questions regarding what behaviors are considered legal and heplful, and what behaviors are considered academic dishonesty. See the official policy at the UD website: http://www.udel.edu/stuguide/04-05/code.html, and then read this.First: Do not let anyone look at your code. Do not look at someone else's code. That is sharing code, and it is not allowed. Included in this category are all the ways one can share code, such as making it possible for someone to view your code, sending your code via email, and many others.
Second: Penalties for academic dishonesty are typically the same for both the sharer and the sharee; that is, you are just as likely to get in trouble for letting someone see your code as they are for looking at it.
How can I be helpful to another student without violating this policy?
Finally, here is some additional material about script files, written by Prof. Conrad:
- Remember it is the responsibility of the student to seek help early and often from the TAs and instructor; if someone is begging you for help at the last minute, that is not your problem. We can all be sympathetic, but don't use that as an excuse to cross the line and jeopardize your own record.
- You may discuss algorithms in general. Remember when we wrote recipes on the board? You can discuss recipes like that, though you should be careful about writing them down, because they can start to look like a program, and then you would be sharing code. But it is fine to discuss things like "this has to happen before that can happen" (unless that is a specific question in the assignment).
- You can discuss resources: "We had that problem in lab 3, so look at your lab 3 code"; "The book shows that on page 277"; "My TA told me to think of this problem as an eggplant, and now it is clear."
- You can usually work together on problems UNRELATED to assignments. For example, it is ok to work together on programs in your textbook. This gets to be academic dishonesty if, as the project deadline approaches, you are searching for textbook problems that look like the code you are trying to write.
- You can sometime work together on writing small example programs that illustrate an idea, but don't directly solve the assignment. For example, suppose a friend is having trouble writing nested for loops. To help your friend better understand nested for loops, you can write a six line program together that has nested for loops.
HOWEVER, writing an entire function with someone, when that function is part of a required assignment, is NOT ok. Also, it is NOT ok to write several small programs together, the sum of which looks a lot like the assignment or a chunk of the assignment.
- If you have any questions about what is ok or not ok, you can always ask your TA or instructor and we will let you know.
- If you are in doubt, Don't Do It.
- If you are not in doubt, think about whether you should be - review the note above and try thinking like an instructor viewing the question from the outside.
The following are also 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 permissable? 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.- Treat people with respect (especially your TA)
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 neverthless 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 the 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.