Syllabus

Class meetings: 4^th or 5^th period, four times per week: Mondays, Tuesdays, and Fridays, as well as the full 75-minute period on Thursdays.

Book: In the latter half of the course, you may find the Litvin & Litvin Java Methods book a useful reference. Both the second and third edition are fine.

This course is about organizing data in canonical ways so that both client code (the part of the program using the data) and provider code (the part that organizes the data) can work predictably and efficiently. We’ll learn:

• the difference between “abstract data types” (ADTs) and their various implementations,
• the tradeoffs among different approaches to structuring data,
• the circumstances under which each approach is appropriate to use, and
• how to quantify the efficiency of a given technique.

The course is structured in three phases, each of which will be driven primarily by frequent homework assignments, which we'll spend a lot of time working on during class. These phases concern themselves with:

1. a variety of ADTs: lists, graphs, stacks, queues, dicts, sets, priority queues, and trees;
2. computational efficiency, recursion, sorting, and hashing; and
3. a variety of implementations for the above ADTs, as well as lower-level ADTs such as heaps.

You may find it useful to examine my overview diagram, which shows all the ADTs and implementations we'll talk about this term (plus a handful of extras). Amazingly, you'll understand this diagram by the end of the term!

Please bring to class each day both a computer and tools to take notes. We will primarily be relying on class notes in this course, rather than a textbook, so it's important that you take notes every day. In addition, your notes will involve drawing pictures, so be sure your note-taking setup allows for this.

This class is designed to be manageable for a hard-working and focused student with a clear understanding of the material covered in the first two terms of Comp 500. It will be more work than Comp 500, with assignments that will each take several hours. They are paced throughout the term in such a way that you should be able complete each one by devoting about an hour each day outside of class time. However, there are two important things to note:

• The amount of time required to complete a math- or programming-intensive assignment (like all the ones assigned in this course) is usually hard to predict; in particular, by definition it is unknown how long you might need to spend debugging your work. The first 80% of an assignment will generally take you less than 20% of the time. This means that the one-hour-per-night quantity above is an approximate average, over students and over the term.
• All of this means that, in order to maintain a manageable workload in this class, you must start each assignment promptly. If you wait until the last minute, development will blow up in your face. Fortunately, we're going to start most assignments in class, so you should have a little time to get going right away on each one.

It’s inevitable that variations in prior experience will affect how much extra work needs to be put in by each individual student. I try to do a good job aiming the course at a level that’s achievable for everyone, but for some people that may involve a pretty tremendous effort, while others can do it fairly readily.

If you are struggling in this class, please come talk to me as soon as possible. I'm always here to support you, and I know everybody comes in with different background. In addition, the schedule for this course is not set in stone, and if many people are struggling, it can be modified to keep it manageable for the majority of students.

If you need help with anything, you can post to Piazza, consult with other students, consult with a teddy bear (really! It works!), search online, or meet with me. Piazza will be the class's main medium of communication outside of class time. Please follow these guidelines:

• Anyone in class can ask or answer questions, so please do both!
• If you want to ask me a question, please use Piazza. Make your question public unless there's a particular reason to make it private — other people may have the same question.
• Keeping up with what's asked and answered on Piazza is part of the requirements of the course. If a question gets answered on Piazza, I'm going to assume that everyone has read it.

I try to answer questions promptly on Piazza, though I generally don't answer late in the evening or on weekends.

If you'd like to talk with me in person, I'm available in Morse 103 during conference period each day, as well as my office (Morse 102) during advising period. You are always welcome (and encouraged!) to drop by unannounced in conference period or advising period — no need to check with me in advance.

If you'd like to meet with me outside of conference period, please email me about a day in advance. I'm often free during 3rd, 6th, and 7th period, since I don't teach then.

Please ask by email at least 15 minutes (but preferably 15 hours) in advance if you would like to request Personal Time. Requests will generally be approved but I do have the right to decline any request.

Please get to class on time. Three unexcused tardies count as one unexcused absence. If you're wondering about your status in this regard, please ask. Being off-task during class time is distracting and will count as an unexcused tardy.

Every assignment in the course is worth some number of points, typically about 25. There will be four quizzes throughout the term, each worth about 40 points. There will be one final exam, worth something like 150 points. All points are equivalent, and your final grade will be computed as the percentage of total points earned out of all points possible. Here's the mapping to the PA grade scale:

Late work will incur a penalty of 10 percentage points per 24-hour period by which it is late. (For example, a submission half an hour after the due date incurs a 10-percentage-point penalty; a submission 24.5 hours late incurs a 20-percentage-point penalty.)

A set of assignments near the end of the term will be designated as leave-one-out assignments; from this set, you are free to not turn in one assignment of your choice.

Unless stated otherwise, everything is due 15 minutes before class time on the due date specified.

There are a variety of sources of information about assignments in this class. They should all agree, but sometimes these systems get out of sync by accident. If you find a discrepancy between two sources of information, please email me immediately (or post to Piazza) and let me know; I'll resolve it right away. Once you've alerted me, you should proceed in the meantime with the most authoritative source of information. Here are a few, listed from most to least authoritative:

• The individual assignment's webpage — this is considered the “document of record”.
• The main course website.
• The assignment hand-in spot on Canvas.
• Things I say in class.

Unless explicitly specified otherwise, all of the following expectations apply to every assignment you do for this class:

• All homework that you submit must include, at the top, a title, your name, the submission date, my name, the name of the class, and your class period. This includes every source-code file that you write (where these details should be included in a comment at the top of the file) as well as all other writing.
• In every Java file you write, you must include a Javadoc comment on each class, each constructor, and each method. The only exception is the main method in a class that contains nothing else. Javadoc comments must be written with correct capitalization and punctuation, and should use complete sentences or well-formed sentence fragments.
• Every data-structure implementation that you write must be accompanied by a class that tests it; you may also be instructed to write tests in other circumstances too. For most of the term, the tool we'll use to write tests is JUnit, which we'll learn about in class.
• Code style and structure matter in this class. You must use consistent indentation, spacing, and bracket style, and no tab characters are allowed in your source code. Write clear comments (in complete sentences, with correct capitalization and punctuation) to explain tricky portions of code. Avoid repeated code and repeated calls that will have the same result. In technical writing, one must always aim for a balance of clarity, conciseness, and precision; the same is true in code.

Learning and coding are both collaborative arts. However, any work you turn in must be your own work (or, in a group assignment, the work of you and your partners together). You are free to consult with any of the resources mentioned above, but you are required to credit any assistance you receive, in writing, in what you turn in. You should be prepared to explain any part of anything you submit, without the assistance of anyone else, even partners. It is your responsibility to make sure that you fully understand the work that you create, alone or in a team.

There are two kinds of working together: Collaboration and Plagiarism. The former is usually encouraged; the latter is forbidden. But when you're starting out, it can be hard to tell the difference between them. The two essential distinctions have to do with transformation and attribution:

Transformation

The artifact (writing or code) that you submit must be entirely your own work (every last word of it). Copying someone else's work and making surface-level changes to it (like renaming variables or rewriting comments) is not acceptable. Learning from online or book sources, or from working through related problems with a friend, is accepted and encouraged! The point is to get the ideas into your brain, to understand them, and then transform them into work that is all your own. It's no good to bypass your brain and just copy things

Attribution

If any ideas embodied in your work were provided or inspired by someone or something other than yourself (or your team), you must cite this source. In written work, this belongs in a footnote or citation; in code, this belongs in a prominent comment.

Examples of positive collaboration, which is encouraged!

• Reading a book or website about topics covered in our class.
• Reading a book or website together with a friend, and discussing it together.
• Copying a classmate's class notes (with their permission, of course).
• Sharing code with a classmate (or even the entire class) about a problem related to some aspect of an assignment, but doesn't just give you the answer to the assignment task itself. For example, say that both the assignment and some other task, X, both involve allocating arrays of generic-type objects in Java. Telling a fellow student exactly how to do task X, or directing them to a resource that tells them how, is usually totally fine.
• Studying code you find online or in a book that is related to some aspect of an assignment, but doesn't just give you the answer to the assignment task itself.
• Asking your classmates a question about a concept relevant to this class (or answering such a question).

Examples of negative collaboration, which is prohibited:

• Asking a classmate to show you exactly how to do some portion of an assignment.
• Showing a classmate exactly how to do some portion of an assignment, or pointing them to a resource that shows the answer without explaining it in any deep way.
• Asking a classmate for help in such a way that you show them significant portions of your code for solving an assignment.

Plagiarism, which is prohibited by school policy:

Plagiarism is the process of (intentionally or unintentionally) presenting the work of someone else in such a way that a reader might assume it was your own. Directly copying someone else's work and performing only surface-level modifications to it is plagiarism, even if you credit your source. Here are some examples of plagiarism, which is prohibited by the school — note that this list is non-exhaustive:

• Copying someone else's code or writing, changing the variables or comments or words around, and turning it in.
• Finding code or writing on the internet, changing the variables and comments around, and turning it in.
• Finding code in a book to do a particular task, changing the variables and comments around, and turning it in.

Penalties for plagiarism or cheating include formal disciplinary action, a zero for the relevant assignment, and possibly more significant impacts on your grade for the course.

If you have any uncertainty about a particular instance of working together, make sure to check with me first.