Welcome to CS 61B
The CS 61 series is an introduction to computer science, with particular
emphasis on software and machines from a programmer's point of view.
CS 61A covered high-level approaches to problem-solving, providing you with
a variety of ways to organize solutions to programming problems as
compositions of functions, collections of objects, or sets of rules. In
CS 61B, we move to a somewhat more detailed (and to some extent, more basic)
level of programming.
In 61A, the correctness of a program was our primary goal. In CS61B,
we're concerned also with engineering. An engineer, it is
said, is someone who can do for a dime what any fool can do for a dollar.
Much of 61B will be concerned with the tradeoffs in time and memory for
a variety of methods for structuring data. We'll also be concerned with the
engineering knowledge and skills needed to build and maintain moderately
This class assumes you have taken CS61A, CS61AS, or E7, or have equivalent background to a student who has taken one of these courses. The course is largely built upon the assumption that you have taken CS61A or CS61AS, and E7 students may find the beginning of the course to be a bit scarier, particularly when it comes to object oriented programming.
We assume you are coming in with zero Java experience. Nonetheless, we will move through basic Java syntax very quickly. Though the syntaxes of Java, Python, MATLAB, Scheme, etc. are enormously different, the underlying computational models are surprisingly similar.
If you already have Java experience, great! We hope that you'll help out your fellow students in discussion, lab, and on Piazza, particularly in the opening weeks when everyone is catching up on Java.
Knowledge of UNIX is not required, though you might find it useful if you want to use the lab computers instead of your own computer. Lab 1 will give you resources to learn UNIX if you end up deciding use the lab computers instead of your own.
Is this the right course for me?
This is a course about data structures and programming methods. It happens to also teach Java,
since it is hard to teach programming without a language. However, it is not intended
as an exhaustive course on Java, the World-Wide Web, creating Android apps, user interfaces,
graphics, or any of that fun stuff.
Some of you may have already had a data structures course, and simply want to learn
Java or C++. For you, self-study may be a better option. CS 9F (C++ for programmers) and
CS 9G (Java for programmers) are both one-unit self-paced courses that will teach you more
of what you want to know in less time. There is no enrollment limit for that course, and
you work through it at your own pace after the first and only lecture.
Finally, the 1-unit self-paced course CS 47B is for students "with sufficient partial credit
in 61B," allowing them (with instructor's permission) to complete the 61B course requirement
without taking the full course.
Discussion and Lab Sections
Each week there is a 1 hour discussion section and a 2 hour lab section headed by a GSI and supported by volunteer lab assistants. Information about the staff running each section can be found on the staff page
If you decide to permanently switch sections, it'd be best to switch in CalCentral. However, if the section is officially full or doing so would somehow cause you significant grief, it's OK to simply clear it with the two TAs involved.
Discussion attendance is not mandatory, but each discussion you attend earns you "one gold point" (up to a maximum of 10), which are extra credit points described in more detail below. Attendance will not be taken for the first two weeks. Lab attendance is optional for most labs, but we think you'll find it useful to go anyway. Attendance of the project 1 code review lab and the project 2 design lab are mandatory. Lab deadlines on gradescope will always reflect the "true" deadline (in the event that we need to push anything back for reasons like technical glitches).
Lab materials are available online, so you will be able to do much of the work ahead of time. Nonetheless, we encourage you to attend your scheduled lab time. One major purpose of the labs is to give your TA a chance to check up on you and to find out what people are and are not understanding. We've found that with the increasing ability to work anywhere has come an increasing tendency for students to go off by themselves and fall behind. Don't make this mistake. Keep up with homework and lab work and above all let us know when you don't understand something!
The course home page
will provide one-stop shopping for course information.
The course schedule as well as all handouts, homework, labs, FAQs, etc., will be posted there.
Our discussion forum this semester will be Piazza
For most questions about the course, Piazza is the right place to ask them. The course staff
read it regularly, so you will get a quick answer. Furthermore, by posting online
as opposed to emailing us directly, other students benefit by seeing the question and
the answer. Don't forget to check Piazza before asking your question, just in case
someone else has already posted it.
The e-mail address firstname.lastname@example.org
will send a message to the course staff (Josh and the head TAs). You can use it for
correspondence that you don't want to send to Piazza. We all read it, so you will usually
get a quick reply. If you send a question that is of general interest, we may post the
response on Piazza (we will keep personal information out of it, of course). If you have any problems that require an exception (e.g. medical emergencies, sudden necessary travel), please contact email email@example.com
. Emailing only your TA or Josh may result in significant delays in resolving your issue.
To talk with us, the best way is to come during regular office hours (posted on the home page).
Many of us are available at other times by appointment. Please don't be shy. Web pages, email,
and Piazza are useful, but it's still much easier to understand something when you can
talk about it face-to-face. Even if you're an "online section" student, you're still welcome to come to office hours. Office hours are concentrated Monday to Wednesday because we hold labs all day Thursday and Friday.
I've written our own course notes for the first seven weeks of the course. These should be sufficient for you to understand what we need to know about Java. They can be found at https://joshhug.gitbooks.io/hug61b
The optional textbook for the weeks 8-14 of the course is Algorithms, 4th Edition
by Wayne and Sedgewick.
All textbooks for this course are optional. Homework will not be assigned from them, and alternate readings will be provided when possible.
description of the Java core language is available online in
The Java Language Specification
(Java SE 8 Edition) by James Gosling, Bill Joy, Guy Steele, Gilad Bracha, and Alex Buckley. It's extremely thorough and easy to read (once you understand how to read it).
This official coding environment and text editor for the course is the Integrated Development Environment (IDE) called IntelliJ, though we will not introduce this IDE until Week 2. At your own discretion, you may instead use Vim, Emacs, Sublime, or
IDEs like Eclipse, Netbeans, Emacs etc. Whatever you use, however, your
submitted solutions must conform to our expected layouts, as indicated in the assignments. We strongly recommend that you use IntelliJ starting as soon as you finish project 0. We will not officially support any editing environment other than IntelliJ.
This semester, we will be using Java 8. It is already installed on the lab computers, and it
may be provided with your computer as well.
You will be able to do any work you'd like on any Windows, Mac OS X, or Linux computer. You may also remotely log into the instructional machines (which you will receive an account for during the first week), though you should be able to most everything in the course by working natively on your own computer. Information for setting up your own computer is linked in lab 1b
We'll be using the version-control system Git
Version-control systems allow you maintain a series of "snapshots" of your files at
various points in their development. Used properly, this provides you some back-up
protection, so that you can recover previous states of your work when something goes wrong.
Also for team-oriented projects (as well as in the real world), version-control systems
help manage collaborative work.
You will be learning and using Git for this course to track your work and submit your assignment. In addition to the advantages above, using Git will allow the staff to track your progress in the course and maybe even help you out when you're stuck on bugs. The first lab will teach you the basics of what you will need to know. Feel free to
also read official Git documentation
HWs and Labs
There will be 14 labs and 7 homeworks. During Phase I of the course (Weeks 1 through 4), labs will provide you with help getting your computer set up. During Phase II of the course (Weeks 5 through 7), labs will provide you with structure for the open ended design project (project 2). In Phase III of the course, labs will give you a chance to implement important data structures and algorithms. All labs will take approximately two hours to complete, though some may run slightly longer. HWs will vary from 3 to 10 hours of work. You will turn in everything electronically using GitHub, and your results will be available on Gradescope. All homeworks and labs are individual efforts (without partners). Two of the homeworks and one of the labs will be released during RRR week. If you complete all of your work during the semester, you don't need to do these (as they will be dropped). For the two labs with no official work to turn in (labs 7 and 11), everybody gets a full score of 4/4 points automatically, even if they do not attend lab that week.
Homework will be graded on a rigorous suite of correctness tests while labs will receive full credit for "reasonable effort," as evaluated by a small number of relatively simple correctness tests. Passing all tests on Gradescope for homework or labs will ensure full credit as there are no hidden tests. Each lab will be worth 4 points (for a total of 48 points), and each homework will be worth 16 points (for a total of 80 points). Grades will be rounded to the nearest tenth of a point.
No extensions or grace hours will be granted for labs or homework. To allow for situations that may arise in the course of life, we only count your 12 best (out of 15) labs and 5 best (out of 7) homeworks. In the event that you have an emergency where you need to drop additional homeworks or labs, please email the staff at firstname.lastname@example.org
In addition to the HWs and labs, there will be 4 programming projects. In these projects you will build an entire system.
For project 0, you will be able to work with a partner
. For project 2 you will be required to work with a partner, unless you specifically request otherwise (details TBA).
Project 0 and 1 will be relatively easier than projects 2 and 3, taking less time and with greater levels of scaffolding. Project 2 will be a very difficult project (on par with what you might expect from Hilfinger's harder projects). Project 3 will be challenging, but not as time consuming as project 2.
Each project has a specific theme:
- Project 0: Introduction to Java
- Project 1: Basic Design, Testing, and Code Review
- Project 2: Large Scale Design and Testing
- Project 3: Working with an Existing Code Base
For all projects, we will ultimately release all tests that determine your grade. In other words, passing all tests on Gradescope will allow you to earn full points for the autograded portion of the project.
Projects 0, 1, 2, and 3 will be worth 25, 40, 100, and 75 points respectively. For projects 2 and 3, there are opportunities for "gold points" described in each project specification.
There will be two evening midterms, tentatively on February 14th and March 22nd and a final exam on May 10th at 7 PM. You will be allowed to bring one letter size page of handwritten notes (front and back) to the first midterm, two to the second midterm, and three to the final. You will not be required to turn in these sheets, and you may reuse them from exam to exam.
Inspired by the great Paul Hilfinger tradition, exams
may cover any material whatsoever. For fear of our lives, exams will almost exclusively test material covered in the course.
Inevitably, some of you will have conflicts with the scheduled exam times. We will
arrange for alternative test times for those people who have sufficient cause.
Sufficient cause includes conflicting exams for other courses, medical or family
emergencies, or important religious holidays (however, we believe we have avoided all of
We will provide a form several weeks before each exam for students to request alternate exams, which will almost certainly occur after the regular exam has occurred. With the obvious exception of emergencies, you must fill out this form by the provided deadline to be considered for an alternate exam.
Popular reasons that are not sufficient cause include having job interviews,
having a plane ticket that you (or your parents) bought without consulting the schedule,
having exams or assignments in other courses at nearby times, being behind in your reading,
being tired, or being hung over.
We release grades for exams on Gradescope
If you believe we have misgraded an exam, request a regrade on the same site with
a note explaining your complaint. You should check the online solutions first to
make sure that this regrade will make your total score go up as it is possible to lose
points from a regrade request.
Midterm 1 grades will be available by the night of Jan 15th, giving you two days to decide whether to drop the course. If you're a prospective CS major and you do poorly, we will provide advising sessions to help you decide what to do. Details will be announced at that time.
If your midterm grades are statistically much worse than your final, we'll replace your midterm grade under the "shadowing" policy below. You should not depend on shadowing to substantially improve your grade. Very few students receive a significant benefit.
Midterm (both MT1 and MT2) grades can be "shadowed" (aka a weaker version of what Dan Garcia calls "clobbering") by the final. The way it works is that if you are X standard deviations from the mean, your midterm scores will be replaced by a score equivalent to X - 0.5 standard deviations from the mean. This policy can only help, and cannot hurt your score.
Effectively, this only applies if you improve substantially on your final: an improvement of over 0.5 standard deviations.
For example, suppose Bilbo scored 0.4 standard deviations above the mean on MT1, 0.9 standard deviations above the mean on MT2, and 1.1 standard deviations above the mean on the final. Then Bilbo's midterm scores will be replaced by 1.1 - 0.5 = 0.6 standard deviations above the mean, as long as this is an improvement.
Since Bilbo already got 0.4 above the mean on MT1, his score would be replaced by 0.6. However, his score on MT2 would not be changed (since he is already 0.9 above the mean).
As another example, suppose Bilbo is -1.1 above the mean on MT1, -0.1 on MT2, and 0.3 on the final, his midterm scores would be replaced by -0.2 (0.3 - 0.5) if that helps. In Bilbo's case, his MT1 score would be replaced by -0.2, and MT2 score would be untouched (since it is already better).
Or in pseudocode:
your_devs = (your_final_score - final_mean) / final_stddev
your_potential_replacement = (your_devs - 0.5) * midterm_stddev + midterm_mean
your_shadowed_midterm_score = max(your_midterm_score, your_potential_replacement)
Your letter grade will be determined by the total points out of the possible 768.
In other words, there is no curving in this course, other than the shadowing policy above. Your grade will depend solely on how well you do,
and not on how well everyone else does. Unlike other CS courses, the grading bins for 61B generally do not get tweaked at the end of the semester.
|Homework/Labs ||~16.6% ||128
|Projects ||~31.3% ||240
|Midterms ||~26% ||200
|Final Exam ||~26% ||200
|Total ||100% ||768
Departmental guidelines suggest that the average
GPA for a lower-division required course be in the range 2.5 - 2.9,
with 2.7 (B-) being typical. This corresponds to getting 55% on
tests (typical for past exams), 75% on projects, and 100% on homework and lab assignments.
We will grant grades of Incomplete only for dire medical or personal
emergencies that cause you to miss the final, and only if your work up to
that point has been satisfactory. Do not try to get an
incomplete simply as a way to have more time to study or do a project.
That is contrary to University policy.
There will be a total of 16 points of extra credit in the course:
- 3 points each for projects 2 and 3. Details in project specs.
- 2 points for the pre-semester survey (released 1/18).
- 2 points for mid-semester survey.
- 4 points for taking the staff created end-of-semester survey.
- 2 points for taking the official university end-of-semester survey.
There are two ways to earn gold points: Attending discussion and completing the 'stretch' goals on project 2 and 3. Gold points act sort of like extra credit, though the higher your exam scores, the less your gold points will count. You should only pursue project gold points if you really enjoy the projects, as the amount of credit you'll earn per hour spent is relatively low compared to other facets of the course (e.g. exam studying).
If you earn g gold points T points on all exams (after taking into account shadowing), then your total score in the course will be boosted by 2*(g - g * T/400).
For example, if you earn 2 gold points on project 2, 6 gold points from attendance, and have 240 points on your exams total, then you'll earn a gold boost of 2*(8 - 8 * 240/400) = 6.4 to your total score in the class.
If we decide a project is too difficult, we reserve the right to move some part of the project into the gold parts section. In such a case, we may readjust the distribution of gold points.
Policy on Collaboration and Cheating
Deadlines can be stressful, and we know that under extreme pressure, it becomes tempting to start rationalizing actions that you would otherwise yourself consider inappropriate. Perhaps you'll find yourself facing a 61B project deadline, and under all this stress you'll convince yourself that you're just going to cheat for the moment so you can get the points, and that you'll come back later and really learn the thing you were supposed to have learned in order to restore your karmic balance (I've heard something along these lines a few times).
This is a terrible idea. Obviously it's important to learn how to deal with deadlines, but far more important than that, giving into this sort of pressure under not-so-dire circumstances is going to do some damage to your moral compass. Someday, when the consequences are higher than potentially losing a 1/3rd of a letter grade, you may find yourself committing dishonest acts at the cost of someone else's livelihood or life.
Plagiarism on any hw, lab or project will result in a score of -50 on that assignment, which will likely reduce your letter grade by several bins. A second instance of plagiarism on a homework, lab, or project will result in an F in the course. All incidents of plagiarism will be referred to the Office of Student Conduct, including carelessly leaving code up on GitHub.
HW and Lab Collaboration Policy
In CS61B, we have three types of assignments: homeworks, labs, and projects. The entire point of homeworks and labs is to learn. For homeworks or labs, you should feel free to collaborate with others however you choose, though keep in mind that greater independence is likely to give you a better learning experience (as long as you aren't totally stuck). Even though we will allow close collaborations on HWs and labs, your code should still be your own work! Identical or near identical submissions will be treated as plagiarism.
Project Collaboration Policy
By contrast, the projects were designed not just for learning (particularly how to be self-reliant in the context of large unfamiliar systems), but also for the dual purpose of evaluating of your mastery of the course material. As such, they are intended to be completed primarily on your own (or with your partner for the first two projects), particularly when it comes to writing the actual code.
For exams, we will be absolutely unforgiving. Any incident will result in a failing grade for the course, though Berkeley will let you retake 61B next semester. As above, all incidents of cheating will be referred to the Office of Student Conduct.
What constitutes cheating? The golden rule of academic dishonesty is that you should not claim to be responsible for work that is not yours.
This is obviously open to some interpretation, and you'll be getting some help from instructors, the internet, other students, and more throughout the course. This is OK, and we hope that the class is an open, welcoming, collaborative environment where we can help each other build the highest possible understanding of the course material.
To help (but not entirely define) the bounds of acceptable behavior, we have three important rules for projects:
- By You Alone: All project code that you submit (other than skeleton code) should be written by you (and if applicable, your project 0 or project 2 partner) alone, except for small snippets that solve tiny subproblems (examples in the Permitted section below).
- Do Not Possess or Share Code: Before a project deadline, you should never be in possession of solution code that you (or your partner) did not write. You will be equally culpable if you distribute such code to other students or future students of 61B (within reason). DO NOT GIVE ANYONE YOUR CODE -- EVEN IF THEY ARE DESPERATELY ASKING. DO NOT POST SOLUTIONS TO PROJECTS ONLINE (on GitHub or anywhere else)! If you're not sure what you're doing is OK, please ask.
- Cite Your Sources: When you receive significant assistance on a project from someone else, you should cite that assistance somewhere in your source code. We leave it to you to decide what constitutes 'significant'.
For clarity, examples of specific activities are listed below:
- Discussion of approaches for solving a problem.
- Giving away or receiving significant conceptual ideas towards a problem solution. Such help should be cited as comments in your code. For the sake of other's learning experience, we ask that you try not to give away anything juicy, and instead try to lead people to such solutions.
- Discussion of specific syntax issues and bugs in your code.
- Using small snippets of code that you find online for solving tiny problems (e.g. googling "uppercase string java" may lead you to some sample code that you copy and paste into your solution). Such usages should be cited as comments in your hw, lab, and especially project code!
Permitted with Extreme Caution
- Looking at someone else's project code to assist with debugging. Typing or dictacting code into someone else's computer is a violation of the "By You Alone" rule.
- Looking at someone else's project code to understand a particular idea or part of a project. This is strongly discouraged due to the danger of plagiarism, but not absolutely forbidden. We are very serious about the "By You Alone" rule!
- Working on a project alongside another person or group of people. Your code should not substantially resemble anyone else's!
- Possessing another student's project code in any form before a final deadline, be it electronic or on paper. This includes the situation where you're trying to help someone debug. Distributing such code is equally forbidden.
- Possessing project solution code that you did not write yourself (from online (e.g. GitHub), staff solution code found somewhere on a server it should not have been, etc.) before a final deadline. Distributing such code is equally forbidden.
- Posting solution code to any assignment in a public place (e.g. a public git repository, mediafire, etched into stones above the Mediterranean, etc). This applies even after the semester is over.
- Working in lock-step with other students. Your workflow should not involve a group of people identifying, tackling, and effectively identically solving a sequence of subproblems.
We have advanced cheating detection software, and we will routinely run this code to detect cheating. Every semester, we catch and penalize a significant number of people (71 cases in Spring 2016). Do not be one of them. If you find yourself at such a point of total desperation that cheating begins to look attractive, contact one of the instructors and we can maybe help somehow. Likewise, if 61B is causing massive disruption to your personal life, please contact us directly.
If you admit guilt to an act of plagiarism before we catch you, you will be given zero points on that assignment, and we will not refer your case to the university administration.
Obviously, the expressive power of Java is a subset of the English language. And yes, you can obviously obey the letter of this entire policy while completely violating its spirit. However, this policy is not a game to be defeated, and such circumventions will be seen as plagiarism.