UCR CS 14: Introduction to Data Structures And Algorithms

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 dishonesty 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/.
  • Academic dishonesty statement - All students are required to sign a statement in lecture during the first lecture, or in office hours the first week, stating what resources are allowed for the course and how to find help.
  • 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.
  • Written 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 completed 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 - Limited collaboration may be acceptable, but programs must represent YOUR OWN original work. Sharing code or team-coding are strictly not allowed. Copying code from ANY source (any book, current or past students, past solutions, 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. 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 inadvertently obtain a copy of your code. 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 digitally scanned and archived. Those scanned 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, all electronics (cell phones, PDAs, calculators, etc) 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 should 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.
• 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, running at double speed. As such, you should expect to spend 6 hours/week in lecture, 6 hours/week in lab, and 12 to 20 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.
• 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 - 5% for 1 day late, 10% for 2 days late. Assignments will not be accepted after 2 days.
  • BONUS for any at home programming assignment turned in EARLY - 3% for 1 day early, 6% for 2 days early, and 9% 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. It makes CS 141 and further classes significantly easier, so practicing with it now is a Good Idea.
  • 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++ Standard Template Library: A Tutorial and Reference Easily one of the most useful books to have on your desk.
  • 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
  • C++ in a Nutshell pre-release web page.
  • Practical C++ Programming.

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