UCR CS 14: Introduction to Data Structures And Algorithms

Spring Quarter 2005

Overview

Basic information

Course schedule

General course features and policies (please read these carefully)

• Material covered: You'll be responsible for learning material covered in lecture, in the textbook, and in lab. Lecture does not cover all required material alone. Be prepared for homework/quiz/midterm/final questions on material from the readings that was not covered in lecture.
• Academic integrity and collaboration policy: cheating is strongly punished, often with an F in the course, plus a letter to the vice-chancellor; UCR suspends or expels repeat offenders. Help us detect cheating by reporting cheating anonymously at: https://www.cs.ucr.edu/cheating/. You should also visit the offical Judicial Affairs webpage for the University.
  • Academic integrity statement - All students are required to sign both the academic integrity guidelines for this class and the adademic integrity guidelines of the University to verify that you have read and understand these guidelines. You should also read the University policies. Students not submitting the signed statement will receive a grade delay in the class until the form is returned.
  • Midterm, final, quizzes, lab practicals - Obviously there will be no collaboration allowed in any of these areas
  • In-class exercises - Dependent on instructor instructions for a particular exercise.
  • Homeworks - Collaboration is strongly ENCOURAGED. Study groups are very helpful for learning. Collaboration should consist of discussion of the homework problems and steps necessary to complete them. However, you should write out your own solutions. You should not turn in *identical* solutions as others, but similar solutions are okay. You should write up the final solutions yourself.
  • In-lab exercises - Collaboration is strongly ENCOURAGED. If you complete an exercise, feel free to help others -- teaching enhances your own learning. However, you should not show your code to those you are helping nor should you ever write code for them. Rather, try to lead them towards the correct answer with hints, or help them debug. Copying code from ANY source (any book, current or past students (excluding your current lab partner), past solutions, web, etc) is strictly not allowed even with citation.
  • At-home programming assignments - Very limited collaboration MAY be acceptable, but programs must represent YOUR OWN original work. Sharing code or team-coding are strictly not allowed (even if team-coding was acceptable in a previous class, this course DOES NOT allow team-coding). Copying code from ANY source (any book, current or past students, past solutions, any work you have turned in for a previous class, web, etc) is strictly not allowed even with citation. Collaboration may consist of discussing the general approach to solving the problem, but should not involve communicating in code or even pseudo-code or discussion of details. Students may help others find bugs. Your code MUST be unique -- the odds of randomly producing similar code is very low. Computing, like surgery or driving a car or playing golf, can only be learned by doing it yourself!
  • PROTECT YOUR CODE!! - Do not allow anybody to purposefully or inadvertently obtain a copy of your code even after this course is completed. For example, if you print your code and the printer is out of paper, DO NOT LEAVE. Either get paper from systems or cancel your print job. If you leave, later on someone will put paper in the printer and out will come your code. Furthermore, do not throw any code into the trashcans in the lab.
  • It is considered against computer account policy to tamper with another's account. Thus, if you give someone else your password and they copy your work or turn something in for you, both parties will have committed academic dishonesty.
  • Be aware that programs are automatically compared to the current and prior quarter's programs for plagiarism, using a sophisticated code-comparison tool that ignores insignificant differences (like whitespace and variable names). If you're smart enough to fool the instructors, TAs, and code-comparison tools, you're more than smart enough to do the programs on your own!
  • A couple more notes. Be aware that completed exams are photocopied. Those photocopies may be used for comparison with exams submitted for regrades, so don't make changes. Also, be aware that lying to an instructor in order to be able to make up a missed exam or in other ways to obtain a better grade can be treated as academic dishonesty. During exams, cell phones and PDAs must be stored away in a place not visible (e.g., inside a backpack).
• Regrade policy: regrade requests must be submitted in writing and within one week of the distribution of the graded material. Grade-database errors must also be pointed out within one week of posting.
• Final grades: Per university policy, changes to your final grade will be made only in the event of a clerical error. Asking your instructor how far you were from a cutoff and what extra work you can do to improve the grade is not appropriate.
• Switching/adding/dropping lab and lecture sections: all add, drop, and section changes of all lower division Computer Science courses, after the period when students can do so electronically is over, are done through the College of Engineering's Student Affairs office. Neither the instructors nor the CS department itself can sign any add/drop forms, nor can they arrange for section changes. Please go to Student Affairs, Bourns Hall A159, for any such changes. Be aware that if you add the course late, you WILL NOT be allowed to make up any course work that you have missed.
• Communicating with the instructors and TAs: when sending electronic mail to the instructors or TAs, please remember that many students have the same name, and instructors/TAs may be involved in more than one course. So please use your full name, preferably including your student ID number, and be as specific as you can (list the course, section, etc. -- whatever is relevant to your communication). Also, please try to be professional and use reasonable grammar and formatting.
• Cell phones: During lectures and lab sessions, please turn off your cell phone.
• Reading: Read the current book sections before coming to lecture, and attend all lectures in their entirety. To encourage these important college study habits, in class exercises will be given for credit.
• Time Requirements: This is a four-unit CS course. As such, you should expect to spend 3 hours/week in lecture, 3 hours/week in lab, and 6 to 10 hours/week doing individual study (readings, homeworks, programming, lab preparation, etc) -- no exaggerating here! Please don't underestimate the time you will need to spend on this course. These are real time amounts spent by successful past students. Computer Science and Engineering are challenging disciplines requiring extensive time to master -- it's worth it in the end (great jobs, great pay, respect, etc.), but those things don't come for free. So practice, practice, practice! Work hard in school, then reap the rewards of a great career.

Lab and At-Home Programming Assignment Guidelines (please read these carefully)

• Students are required to stay the full three hours of lab session every week. You'll have in-lab exercises, discussions, and practical exams. Work ahead or on extra course-related material if you finish early. There is always something new to learn!
• During lab discussion time, students should not use the computers. Ideally, students would move their chairs to the whiteboard area.
• For each lab, you will be required to work with a partner however, each week you MUST work with a different partner to receive credit. To ensure that you will work with different partners, groups will be assigned by the TA for each lab section. Each group will work on one computer together. If your partner does not show up, it is left up to the TAs discretion as to whether or not you will be paired with another student if there is a single student available. (there will be no groups of 3 or more). The labs are designed to complete individually and you are assigned partners so that you can meet new students and learn how to work with others. You will not be at a disadvantage grade wise if you partner does not show up. Remember to put both of your names on the code that you turn in. If your name is not on the code turned in, you may not get credit. You only need to turn in the lab assignment once for each group.
• Prepare for lab before arriving. Even though you will be working with a partner in the lab, you should still look over the lab before hand and make sure that you know enough of the background for the lab to be able to complete it in the time give. The majority of labs will be due 1 hour after the end of your scheduled lab time.
• Lab assignments must be turned in electronically by the time specified on the lab assignment. Additionally, you may be required to check out in lab by showing the TA your working assignment.
• To reduce disruptions and provide for the best educational environment, all persons in lab during scheduled lab time should be formally registered in that section. In general, no swapping sections and no unregistered people in the lab are allowed, even if there are extra computers.
• For programming assignments, labs and lab practicals, you are expected to be able to turn in code that can at least compile. If your code does not compile, you will receive a 0 for the assignment. This means that you should adhere to the following procedure when turning in your assignment: 1) type make clean in your assignment directory, 2) turn in your assignment electronically, and 3 ) return to your assignment directory and type make again to confirm that your assignment compiles. Many projects turned in do not compile because the code was commented (incorrectly) right before it was turned in -- please watch out for that common mistake!
• Lab and at-home programming assignments: All turned-in assignments will be turned in electronically. Each file should begin with our report template header. Source code must comply with professionally accepted coding standards. Also, you must include a section explaining the design, structure, etc of your program and how it works including any special files described with each lab/home programming assignment. Comments in source code are important, but they are not a replacement for an explanatory section. Please remember that successfully writing a computer program that compiles and runs correctly is not something anyone can do in just a few minutes, even when it looks easy. Debugging typically takes three times longer than figuring out how to write your program. So don't leave your programming assignments to the last minute!
• Early/Late policy for at-home programming assignments :
  
  • Late penalty for at home programming assignments - 11% for 1 day late, 21% for 2 days late, and 31% for 3 days late. Assignments will not be accepted after 3 days.
  • BONUS for any at home programming assignment turned in EARLY - 2% for 1 day early, 4% for 2 days early, and 6% for 3 or more days early.
  • "Day early/late" is defined as 24 hours before/after the due time.
• Compilation: all code submitted for at-home programming assignments and in-lab exercises should compile with g++ flags -W -Wall -Werror -pedantic. There will be a minimum of a 10% penalty for at-home programming assignments and in-lab exercises that do not compile with these flags.
• Linux: All home programming assignments are to be done under Linux, or another Unix operating system. Your assignments will be graded on hill.cs.ucr.edu so that is where you should develop your assignments. Submissions that are done under Windows (even if they compile under Linux) may be penalized.
• Electronic Turnin - For all items turned in electronically (home programming assignments, labs, lab practicals, etc), you must turn into your correct lab section. If you do not turn into the correct lab section, it is very likely that your item WILL NOT be graded or will suffer a very heavy penalty.

Additional Resources

• GNU Emacs Reference Card (pdf).


• Books
  
  • Introduction to Algorithms. The best algorithms reference on the market. I highly suggest you pick up this book. It is very difficult to learn how to use but invaluable once you do.
  • C++ Programmer's Guide to the Standard Template Library. A bit old but still touted as one of the best beginners guides to STL around. It is out of print but you can find it at Amazon for very cheap.
  • The C++ Programming Language. Written by the creator of the C++ programming language, Bjarne Stroustrup. This book is an excellent book and is highly advanced -- a must have for any serious C++ programmer.
  • Programmming with GNU Software

© 2003 UC Riverside Department of Computer Science & Engineering. All rights reserved.